Thread: RPMS for 7.1beta3 being uploaded.

RPMS for 7.1beta3 being uploaded.

From
Lamar Owen
Date:
Ok, I have a first set of 7.1beta3 RPMs uploading now.  These RPMs pass
regression on my home RedHat 6.2 machine, which has all locale environment
variables disabled (/etc/sysconfig/i18n deleted and a reboot).

It may take a few minutes to a few hours for the changes I uploaded to
propagate to the public ftp server.

NOTE: BETA RPMS ARE JUST EXACTLY THAT! These RPM's are not in a finished state
-- they are for the express purpose of allowing people to test 7.1beta in an
RPM setup.  Upgrading from a prior version is explicitly NOT supported at this
time.

There ARE KNOWN packaging problems -- I am working on them.

NOTE: there have been some changes in the RPM install structure. 
/usr/lib/pgsql is gone, replaced by /usr/share/postgresql.  See the file lists
from 'rpm -qlp postgresql*7.1beta3-1.i386.rpm' for more details.

README.rpm-dist has not been updated for the 7.1beta3 distribution yet.

To run regression tests, make sure the postgresql-test RPM is installed, then
make sure that the locale environment is set properly.  Regression tests may be
run by first, as root, starting a postmaster: /etc/rc.d/init.d/postgresql start(if there are any errors, make sure you
arenot upgrading!)
 

Then, as root:
chown -R postgres.postgres /usr/share/postgresql/test/regress

(yes, I know the RPMset should do this for you.  It is being fixed.)

Then, su to postgres and cd to /usr/share/postgresql/test/regress.  Execute:
./pg_regress --schedule=parallel_schedule

Any failures indicate an error somewhere -- most likely your locale settings.

Look for another release this week, with things streamlined somewhat.

Also, if you wish to rebuild from the source RPM, please read the comments and
conditionals in the spec file BEFORE rebuilding -- you can conditionally
rebuild just a few of the packages instead of having to rebuild everything.

Please check all the client interfaces you are equipped to check.  I need
someone to work over the perl, python, tcl, and tk stuff.

If someone wants to contribute built jars of the newest JDBC, I would be most
grateful, as I don't have a JDK on my devel machine yet.  The jars distributed
are the 7.0 JDBC jars -- which are known to need some recent patches.

pgaccess currently will not run unless you reconfigure to use -i in the
startup.  This is also being fixed in the RPMset -- there is a change necessary
in postgresql.config, I just have to do the change.

PL/perl is being worked on -- many thanks to Karl DeBisschop for his
perserverence in this.

RPMS are in at:
ftp.postgresql.org/pub/dev/test-rpms
and are built for RedHat 6.2/Intel ONLY.

Once again, at the risk of sounding like a broken record -- these are BETA
QUALITY RPMS -- BY REQUEST.  Please don't make me regret not waiting until a
release candidate :-).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPMS for 7.1beta3 being uploaded.

From
"Oliver Elphick"
Date:
Lamar Owen wrote: >Ok, I have a first set of 7.1beta3 RPMs uploading now. 
...  > >pgaccess currently will not run unless you reconfigure to use -i in the >startup.  This is also being fixed in
theRPMset -- there is a change necess     >ary >in postgresql.config, I just have to do the change.
 
In my experience, pgaccess will use the Unix socket if the hostname is
left blank.  Is this not the case with your RPMs?

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "For I know that my redeemer liveth, and that he shall      stand at the
latterday upon the earth"                                                   Job 19:25 
 




Re: RPMS for 7.1beta3 being uploaded.

From
Peter Eisentraut
Date:
Lamar Owen writes:

> Ok, I have a first set of 7.1beta3 RPMs uploading now.  These RPMs pass
> regression on my home RedHat 6.2 machine, which has all locale environment
> variables disabled (/etc/sysconfig/i18n deleted and a reboot).

Some thoughts:

Re: rpm-pgsql-7.1beta3.patch

| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
| --- postgresql-7.1beta3.orig/src/Makefile.shlib Wed Dec  6 14:37:08 2000
| +++ postgresql-7.1beta3/src/Makefile.shlib      Mon Jan 15 01:50:04 2001
|@@ -160,7 +160,7 @@
|
|  ifeq ($(PORTNAME), linux)
|    shlib                        := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
| -  LINK.shared          = $(COMPILER) -shared -Wl,-soname,$(soname)
| +  LINK.shared          = $(COMPILER) -shared -Wl
|  endif

This cannot possibly be right.

| diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib~ postgresql-7.1beta3/src/Makefile.shlib~

???

| -#!/usr/local/bin/perl -w
| +#!/usr/bin/perl -w
(and more of these for Python)

I think this should be fixed to read

#! /usr/bin/env perl

Any comments?


Re: spec file

| # I hope this works....
|
| %ifarch ia64
| ln -s linux_i386 src/template/linux
| %endif

It definitely won't...

| # If libtool installed, copy some files....
| if [ -d /usr/share/libtool ]
| then
|         cp /usr/share/libtool/config.* .
| fi

This is useless (because the config.* files are not in src/ anymore) and
(if it were fixed) not recommendable because config.{guess,sub} is not
compatible to itself, *especially* in terms of Linux recognition.  You
really should use the ones PostgreSQL comes with.

| %ifarch ppc
| NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
| NEW_CFLAGS="$NEW_CFLAGS -O0"

This is no longer necessary.

| ./configure --enable-hba --enable-locale  --with-CXX --prefix=/usr\

There is no option called '--enable-hba'.  And I think you're supposed to
use %{configure}.

| %if %tkpkg
|         --with-tk --with-x \
| %endif

There is no '--with-x'.  '--with-tk' is the default if '--with-tcl' was
given; you should use '--without-tk' if you don't want it.

| %if %jdbc
|         --with-java \
| %endif

There is no such option.

| %ifarch alpha
|         --with-template=linux_alpha \
| %endif

This won't work and is not necessary.

| make COPT="$NEW_CFLAGS" DESTDIR=$RPM_BUILD_ROOT/usr all

You should set CFLAGS when you run configure. (%{configure} will do that.)
DESTDIR is only useful when you run 'make install'.  And DESTDIR should
not include /usr.

| make all PGDOCS=unpacked -C doc

Not sure what this is supposed to do, but I don't think it will do what
you expect.  The docs are installed automatically.

| mkdir -p $RPM_BUILD_ROOT/usr/{include/pgsql,lib,bin}
| mkdir -p $RPM_BUILD_ROOT%{_mandir}

You don't need that, the directories are made automatically.

| make DESTDIR=$RPM_BUILD_ROOT -C src install

No '-C src'.

| # copy over the includes needed for SPI development.
| pushd src/include
| /lib/cpp -M -I. -I../backend executor/spi.h | \
|         xargs -n 1| \
|         grep \\W| \
|         grep -v ^/| \
|         grep -v spi.o | \
|         grep -v spi.h | \
|         sort | \
|         cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql

I think the standard installed set of headers is sufficient.

| %if %pgaccess
|         # pgaccess installation

Pgaccess is installed automatically when you configure --with-tcl.

| # Move the PL's to the right place
| mv $RPM_BUILD_ROOT/usr/lib/pl*.so $RPM_BUILD_ROOT/usr/share/postgresql

You should not put architecture specific files into share/.  I'm sure this
is in violation of FHS.  (I'm amazed createlang finds it there.)


Re: sub-packages

* pg_id should be in server

* What were the last thoughts about renaming the <nothing> package to -clients?

* pg_upgrade won't work, so you might as well not install it.  It will probably be disabled before we release.

* You're missing pg_config in the -devel package.


These are the things I could find at first glance. ;-)

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: RPMS for 7.1beta3 being uploaded.

From
Lamar Owen
Date:
Peter Eisentraut wrote:
> Lamar Owen writes:
> > Ok, I have a first set of 7.1beta3 RPMs uploading now.  These RPMs pass
> > regression on my home RedHat 6.2 machine, which has all locale environment
> > variables disabled (/etc/sysconfig/i18n deleted and a reboot).
> Some thoughts:
> Re: rpm-pgsql-7.1beta3.patch
> | diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
> | -  LINK.shared          = $(COMPILER) -shared -Wl,-soname,$(soname)
> | +  LINK.shared          = $(COMPILER) -shared -Wl
> |  endif
> This cannot possibly be right.

It's what you recommended a while back.  See the discussions on -soname
from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.
> | diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib~ postgresql-7.1beta3/src/Makefile.shlib~
> ???

Leftover Kedit baggage.  Those are easy to forget to rm during patch
build, particularly at 2:00AM -- but there's no harm in it being there
for now.  And it won't be there in -2.

> | -#!/usr/local/bin/perl -w
> | +#!/usr/bin/perl -w
> (and more of these for Python)
> I think this should be fixed to read
> 
> #! /usr/bin/env perl

No, for a RedHat or any other Linux distribution, /usr/bin is where perl
and python (or their symlinks) will always live.

Although you missed the redundant patches in the regression tree :-).

> Re: spec file
> | # I hope this works....
> |
> | %ifarch ia64
> | ln -s linux_i386 src/template/linux
> | %endif
> 
> It definitely won't...

7.0 required it.  Baggage from the previous build.
> | # If libtool installed, copy some files....
> | if [ -d /usr/share/libtool ]
> | then
> |         cp /usr/share/libtool/config.* .
> | fi
> This is useless (because the config.* files are not in src/ anymore) and
> (if it were fixed) not recommendable because config.{guess,sub} is not
> compatible to itself, *especially* in terms of Linux recognition.  You
> really should use the ones PostgreSQL comes with.

Trond can answer that one more effectively than can I, as that's his
insertion.

Of course, I've got to reorg the destination to match the source tree's
reorg.
> | %ifarch ppc
> | NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
> | NEW_CFLAGS="$NEW_CFLAGS -O0"
> This is no longer necessary.

Depends on the convolutions the particular build of rpm itself is
doing.  This is a fix for the broken rpm setup found on Linux-PPC, as
found by Tom Lane.  It would be marvelous if this would be expendable at
this juncture.
> | ./configure --enable-hba --enable-locale  --with-CXX --prefix=/usr\
> There is no option called '--enable-hba'.  And I think you're supposed to
> use %{configure}.

If it works now, I'll use it.  Version 7.0 and prior wouldn't work with
%{configure}.

And --enable-hba has existed at some point in time.
> | %if %tkpkg
> |         --with-tk --with-x \
> | %endif
> 
> There is no '--with-x'.  '--with-tk' is the default if '--with-tcl' was
> given; you should use '--without-tk' if you don't want it.

There was in the past a --with-x.  So I need to change that to check for
the negation of tkpkg and use --without-tk if so.
> | %if %jdbc
> |         --with-java \
> | %endif
> There is no such option.

Hmmm.  I don't remember when that one got placed there....
> | %ifarch alpha
> |         --with-template=linux_alpha \
> | %endif
> This won't work and is not necessary.

More 7.0 and prior baggage.  The patches for alpha at one point (6.5
through 7.0.3) have required this -- of course, with the need for the
alpha patches gone, the need for the special config step is also gone. 
One more piece of baggage I missed.
> | make COPT="$NEW_CFLAGS" DESTDIR=$RPM_BUILD_ROOT/usr all
> You should set CFLAGS when you run configure. (%{configure} will do that.)
> DESTDIR is only useful when you run 'make install'.  And DESTDIR should
> not include /usr.

Yes, if you'll notice I fixed the DESTDIR in the install. But, of
course, it's not needed (nor is it used) in the build itself.  Again,
I'll use %{configure} when I verify that it works properly (if it does,
that will be a very Good Thing for all involved).  But, again, you're
seeing baggage that 7.0 and prior required in order to build (well,
except DESTDIR).
> | make all PGDOCS=unpacked -C doc
> Not sure what this is supposed to do, but I don't think it will do what
> you expect.  The docs are installed automatically.

Well, they are _now_.  But 7.0 and prior..... again, more old baggage.
> | mkdir -p $RPM_BUILD_ROOT/usr/{include/pgsql,lib,bin}
> | mkdir -p $RPM_BUILD_ROOT%{_mandir}
> You don't need that, the directories are made automatically.

They are _now_.  But before, when the make install put things in the
'wrong' place, it was required to make the directories before doing the
copies and moves necessary.
> | make DESTDIR=$RPM_BUILD_ROOT -C src install
> No '-C src'.

Not anymore, at least.  *sigh*  There has been alot of baggage
accumulate in the spec due to 7.0 and prior's slightly brain-dead
build.  I got rid of a lot of it -- but obviously I missed some.
> | # copy over the includes needed for SPI development.
> | pushd src/include
> | /lib/cpp -M -I. -I../backend executor/spi.h | \
> |         xargs -n 1| \
> |         grep \\W| \
> |         grep -v ^/| \
> |         grep -v spi.o | \
> |         grep -v spi.h | \
> |         sort | \
> |         cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql
> I think the standard installed set of headers is sufficient.

Is it?  It _wasn't_ sufficient for SPI development at 7.0.  Have the
headers and the headers install been fixed to install _all_ necessary
development headers, SPI included?  If so, this step won't add any
headers anyway -- but it would be nice to see the difference.
> | %if %pgaccess
> |         # pgaccess installation
> Pgaccess is installed automatically when you configure --with-tcl.

It is now.  It wasn't previously. At least not to the proper place.
> | # Move the PL's to the right place
> | mv $RPM_BUILD_ROOT/usr/lib/pl*.so $RPM_BUILD_ROOT/usr/share/postgresql
> You should not put architecture specific files into share/.  I'm sure this
> is in violation of FHS.  (I'm amazed createlang finds it there.)

It finds it there because I tell it to :-P.  No, this objection is
definitely correct -- /usr/lib is the right place, and is where it will
live in the future.  Previously, that line moved them to /usr/lib/pgsql.
> Re: sub-packages
> * pg_id should be in server
> * What were the last thoughts about renaming the <nothing> package to -clients?

My thoughts are to leave it the way it is.  I am not alone.  But it's
not set in stone.
> * pg_upgrade won't work, so you might as well not install it.  It will
>   probably be disabled before we release.

Yes, this one needs to not be installed for this release.
> * You're missing pg_config in the -devel package.

Yes, I am.  I noticed that just after I uploaded the rpms from a 28.8
dialup at home.  So, I'll be releasing a -2 set this week to fix that
problem, amongst others.
> These are the things I could find at first glance. ;-)

Some first glance :-)....

Thanks for the feedback.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


$PGDATA/base/???

From
bpalmer
Date:
On older versions of PG,  7.0 included,  in the $PDGATA/base folder you
could see the names of the databases for that $PGDATA.  Now all I see is:

$ ls -l
total 16
drwx------  2 postgres  wheel  1536 Jan 12 15:42 1
drwx------  2 postgres  wheel  1536 Jan 12 15:41 18719
drwx------  2 postgres  wheel  1536 Jan 12 15:42 18720
drwx------  2 postgres  wheel  1536 Jan 15 15:59 18721

Is there a way to relate this to the names of the databases?  Why the
change?  Or am I missing something key here..

- Brandon

b. palmer,  bpalmer@crimelabs.net
pgp:  www.crimelabs.net/bpalmer.pgp5



Re: RPMS for 7.1beta3 being uploaded.

From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Lamar Owen <lamar.owen@wgcr.org> writes:

> Peter Eisentraut wrote:
> > Lamar Owen writes:
> > > Ok, I have a first set of 7.1beta3 RPMs uploading now.  These RPMs pass
> > > regression on my home RedHat 6.2 machine, which has all locale environment
> > > variables disabled (/etc/sysconfig/i18n deleted and a reboot).
>  
> > Some thoughts:
>  
> > Re: rpm-pgsql-7.1beta3.patch
>  
> > | diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
> > | -  LINK.shared          = $(COMPILER) -shared -Wl,-soname,$(soname)
> > | +  LINK.shared          = $(COMPILER) -shared -Wl
> > |  endif
>  
> > This cannot possibly be right.
> 
> It's what you recommended a while back.  See the discussions on -soname
> from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.

Not having a soname doesn't really solve the problem, though... it
should be used, but correctly (major, minor)

> > Re: spec file
>  
> > | # I hope this works....
> > |
> > | %ifarch ia64
> > | ln -s linux_i386 src/template/linux
> > | %endif
> > 
> > It definitely won't...

It did... we've successfully run queries etc on it.

> > | # If libtool installed, copy some files....
> > | if [ -d /usr/share/libtool ]
> > | then
> > |         cp /usr/share/libtool/config.* .
> > | fi
>  
> > This is useless (because the config.* files are not in src/ anymore) and
> > (if it were fixed) not recommendable because config.{guess,sub} is not
> > compatible to itself, *especially* in terms of Linux recognition.  You
> > really should use the ones PostgreSQL comes with.

We have a libtool tuned to work with lots of platforms, like ia64,
s390 etc... this makes sure it's used.

> 

-- 
Trond Eivind Glomsrød
Red Hat, Inc.


Re: $PGDATA/base/???

From
Lamar Owen
Date:
bpalmer wrote:
> 
> On older versions of PG,  7.0 included,  in the $PDGATA/base folder you
> could see the names of the databases for that $PGDATA.  Now all I see is:

No longer.
> Is there a way to relate this to the names of the databases?  Why the
> change?  Or am I missing something key here..

See the thread on the renaming in the archives.  In short, this is part
of Vadim's work on WAL -- the new naming makes certain things easier for
WAL.

Utilities to relate the new names to the actual database/table names
_do_ need to be written, however.  The information exists in one of the
system catalogs now -- it just has to be made accessible.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPMS for 7.1beta3 being uploaded.

From
Lamar Owen
Date:
Trond Eivind Glomsrød wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Peter Eisentraut wrote:
> > > Re: rpm-pgsql-7.1beta3.patch
> > > | diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
> > > | -  LINK.shared          = $(COMPILER) -shared -Wl,-soname,$(soname)
> > > | +  LINK.shared          = $(COMPILER) -shared -Wl
> > > |  endif

> > > This cannot possibly be right.

> > It's what you recommended a while back.  See the discussions on -soname
> > from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.
> Not having a soname doesn't really solve the problem, though... it
> should be used, but correctly (major, minor)

Ok, what's your recommendation for the patch?  I'll look again. 7.0.3-2
shipped with the equivalent patch.  I think I know what you have in
mind, but it will be later tonight before I have time to try it.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPMS for 7.1beta3 being uploaded.

From
Tom Lane
Date:
Lamar Owen <lamar.owen@wgcr.org> writes:
>> | %ifarch ppc
>> | NEW_CFLAGS=`echo $CFLAGS|xargs -n 1|grep -v "\-O"|xargs -n 100`
>> | NEW_CFLAGS="$NEW_CFLAGS -O0"
>> This is no longer necessary.

> Depends on the convolutions the particular build of rpm itself is
> doing.  This is a fix for the broken rpm setup found on Linux-PPC, as
> found by Tom Lane.  It would be marvelous if this would be expendable at
> this juncture.

It is.  7.1 builds cleanly on PPC without any CFLAGS hackery.  I think
we can even survive the -fsigned-char stupidity now ;-)


>> I think the standard installed set of headers is sufficient.

> Is it?  It _wasn't_ sufficient for SPI development at 7.0.  Have the
> headers and the headers install been fixed to install _all_ necessary
> development headers, SPI included?

No, nothing's been done about that AFAIK.  I'm not sure the RPMs should
be taking it on themselves to solve the problem, however.
        regards, tom lane


Re: RPMS for 7.1beta3 being uploaded.

From
Lamar Owen
Date:
Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > doing.  This is a fix for the broken rpm setup found on Linux-PPC, as
> > found by Tom Lane.  It would be marvelous if this would be expendable at
> > this juncture.
> It is.  7.1 builds cleanly on PPC without any CFLAGS hackery.  I think
> we can even survive the -fsigned-char stupidity now ;-)

Oh, good.  Makes it much cleaner.  Care to test that theory? :-)
> >> I think the standard installed set of headers is sufficient.
> > Is it?  It _wasn't_ sufficient for SPI development at 7.0.  Have the
> > headers and the headers install been fixed to install _all_ necessary
> > development headers, SPI included?
> No, nothing's been done about that AFAIK.  I'm not sure the RPMs should
> be taking it on themselves to solve the problem, however.

Just trying to make the postgresql-devel rpm complete, as per request. 
Since the folk who build from source usually still have the source tree
around to do SPI development in, it's not as big of an issue for that
install.

Of course, if the consensus is that the RPM's simply track what the
source tarball does, then that can also be arranged.  But, the precedent
of the RPMset fixing difficulties with the source install has already
been set with the upgrading procedure.

Arguments about why those wishing to do SPI development should install a
full source tree aside, I'm simply providing an RPM-specific requested
feature.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPMS for 7.1beta3 being uploaded.

From
Tom Lane
Date:
Lamar Owen <lamar.owen@wgcr.org> writes:
>> It is.  7.1 builds cleanly on PPC without any CFLAGS hackery.  I think
>> we can even survive the -fsigned-char stupidity now ;-)

> Oh, good.  Makes it much cleaner.  Care to test that theory? :-)

I already did, I believe, but just in plain builds from source.

Let me know when you think the 7.1 RPM specfile is stable enough to be
worth testing, and I'll try to build PPC RPMs.
        regards, tom lane


Re: RPMS for 7.1beta3 being uploaded.

From
Lamar Owen
Date:
Tom Lane wrote:
> Let me know when you think the 7.1 RPM specfile is stable enough to be
> worth testing, and I'll try to build PPC RPMs.

Ok.  Should be coincident with -2. I'm planning to have a -2 out later
this week.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPMS for 7.1beta3 being uploaded.

From
Peter Eisentraut
Date:
Trond Eivind Glomsrød writes:

> We have a libtool tuned to work with lots of platforms, like ia64,
> s390 etc... this makes sure it's used.

We don't use libtool.  Nor does libtool care about the processor.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: $PGDATA/base/???

From
Bruce Momjian
Date:
> > Is there a way to relate this to the names of the databases?  Why the
> > change?  Or am I missing something key here..
> 
> See the thread on the renaming in the archives.  In short, this is part
> of Vadim's work on WAL -- the new naming makes certain things easier for
> WAL.
> 
> Utilities to relate the new names to the actual database/table names
> _do_ need to be written, however.  The information exists in one of the
> system catalogs now -- it just has to be made accessible.

Yes, I am hoping to write this utility before 7.1 final.  Maybe it will
have to be in /contrib.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: RPMS for 7.1beta3 being uploaded.

From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Peter Eisentraut <peter_e@gmx.net> writes:

> Trond Eivind Glomsrød writes:
> 
> > We have a libtool tuned to work with lots of platforms, like ia64,
> > s390 etc... this makes sure it's used.
> 
> We don't use libtool.  

Doing so would be a good thing.

> Nor does libtool care about the processor.

As you can see from the actual code segment, only the
config.{guess,sub} files are copied.
-- 
Trond Eivind Glomsrød
Red Hat, Inc.


Re: RPMS for 7.1beta3 being uploaded.

From
Peter Eisentraut
Date:
Lamar Owen writes:

> > | diff -uNr postgresql-7.1beta3.orig/src/Makefile.shlib postgresql-7.1beta3/src/Makefile.shlib
> > | -  LINK.shared          = $(COMPILER) -shared -Wl,-soname,$(soname)
> > | +  LINK.shared          = $(COMPILER) -shared -Wl
> > |  endif
>
> > This cannot possibly be right.
>
> It's what you recommended a while back.  See the discussions on -soname
> from the libpq.so.2.1 versus libpq.so.2.0 thread awhile back.

The patch I recommended was

-  LDFLAGS_SL            := -Bdynamic -shared -soname $(shlib)
+  LDFLAGS_SL            := -Bdynamic -shared -soname lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)

but that's not what your patch does.  The issue is fixed, you shouldn't
patch anything.

> > I think this should be fixed to read
> >
> > #! /usr/bin/env perl
>
> No, for a RedHat or any other Linux distribution, /usr/bin is where perl
> and python (or their symlinks) will always live.

I was thinking in terms of fixing this in the source tree.

> > There is no '--with-x'.  '--with-tk' is the default if '--with-tcl' was
> > given; you should use '--without-tk' if you don't want it.
>
> There was in the past a --with-x.

But it never did anything.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: RPMS for 7.1beta3 being uploaded.

From
Peter Eisentraut
Date:
Trond Eivind Glomsrød writes:

> > We don't use libtool.
>
> Doing so would be a good thing.

Not if our code is more portable than libtool's.

> > Nor does libtool care about the processor.
>
> As you can see from the actual code segment, only the
> config.{guess,sub} files are copied.

But you argued that this is because your config.guess supports s390 and
ia64 (which ours does as well), but that cannot possibly be libtool
related.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: RPMS for 7.1beta3 being uploaded.

From
Lamar Owen
Date:
Peter Eisentraut wrote:
> The patch I recommended was
> -  LDFLAGS_SL            := -Bdynamic -shared -soname $(shlib)
> +  LDFLAGS_SL            := -Bdynamic -shared -soname lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)

And that is what was in 7.0.3.
> but that's not what your patch does.  The issue is fixed, you shouldn't
> patch anything.

Oh, OK.  Easy enough to delete that section and see where the chips
fall.

> > > #! /usr/bin/env perl

> > No, for a RedHat or any other Linux distribution, /usr/bin is where perl
> > and python (or their symlinks) will always live.
> I was thinking in terms of fixing this in the source tree.

Oh.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPMS for 7.1beta3 being uploaded.

From
Lamar Owen
Date:
Peter Eisentraut wrote:
> Trond Eivind Glomsrød writes:
> > We have a libtool tuned to work with lots of platforms, like ia64,
> > s390 etc... this makes sure it's used.
> We don't use libtool.  Nor does libtool care about the processor.

'We' has a lot of different meanings.  In your sentence, of course, 'We'
is 'the PostgreSQL Global Development Group.'  In my case, I have to use
a 'We' comprised of the PGDG, RedHat, SuSE, TurboLinux, Mandrake,
Caldera, GreatBridge, etc.

The RPM-based Linux distributions have their own consistency
requirements that may at times conflict with 'our' own.  In the case of
packages the are being distributed with these distributions, it behooves
'us' to play by the distribution's rules when those rules don't
negatively affect 'our' primary source distribution.

By having this only in the RPM spec file, it obviates the need for 'us'
to change anything, and it allows 'our' package to be more easily
integrated in the distribution in question.

In particular, this was and is a RedHat-made change. It does not break
anything that I am aware of, and allows the distributions to do their
thing as well.

Therefore, the conditional.  If the distribution doesn't care, then the
files won't exist, and they won't overwrite ours. RedHat 6.1, for
instance.

Is there a technical reason that this would cause a failed or even
non-optimal build?  Non-functional binaries?  Problems at the user
level?

The PPC shenanigans will be gone -- but the libtool stuff -- until
libtoolize works properly on 'our' build (I seem to recall a
distribution that successfully libtollized PostgreSQL -- I'll have to
check.....), this seems reasonable to me in my limited knowledge.

So, Trond, what sort of tunings have been performed that make the files
in question need to be copied?  I'm sure you have a good reason; I am
just curious as to what it is.

Likewise, Peter, I'm sure that from your point of view you have good
reasons -- I'd like to see them as well, for the same reasons as I'd
like to see Trond's.

We're early in the RPM beta cycle here -- many things can and will
change before final.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPMS for 7.1beta3 being uploaded.

From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Peter Eisentraut <peter_e@gmx.net> writes:

> Trond Eivind Glomsrød writes:
> 
> > > We don't use libtool.
> >
> > Doing so would be a good thing.
> 
> Not if our code is more portable than libtool's.

And this is the case? libtool covers pretty much everything... and you
don't need to use it for every target.
> > > Nor does libtool care about the processor.
> >
> > As you can see from the actual code segment, only the
> > config.{guess,sub} files are copied.
> 
> But you argued that this is because your config.guess supports s390 and
> ia64 (which ours does as well)

It may do so now, but I'm pretty sure it hasn't always done so... and
even if it does, it doesn't hurt.
> 

-- 
Trond Eivind Glomsrød
Red Hat, Inc.


Re: RPMS for 7.1beta3 being uploaded.

From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Lamar Owen <lamar.owen@wgcr.org> writes:

> Peter Eisentraut wrote:
> > Trond Eivind Glomsrød writes:
> > > We have a libtool tuned to work with lots of platforms, like ia64,
> > > s390 etc... this makes sure it's used.
>  
> > We don't use libtool.  Nor does libtool care about the processor.
>
> In particular, this was and is a RedHat-made change. It does not break
> anything that I am aware of, and allows the distributions to do their
> thing as well.

Note that this wasn't included in Red Hat Linux 7... it's been done
since then, and I don't remember doing it myself (which of course
doesn't mean I didn't do it :) - it might have been done for the S/390
port, by the people working on that. 
> So, Trond, what sort of tunings have been performed that make the files
> in question need to be copied?  I'm sure you have a good reason; I am
> just curious as to what it is.

For most apps, it's just a question of configure working vs. configure
failing on IA64 (there is no "tuning" as such, my choice of words
wasn't too good). There may be something similar for S/390.


-- 
Trond Eivind Glomsrød
Red Hat, Inc.


Re: RPMS for 7.1beta3 being uploaded.

From
Lamar Owen
Date:
Trond Eivind Glomsrød wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > In particular, this was and is a RedHat-made change. It does not break
> > anything that I am aware of, and allows the distributions to do their
> > thing as well.
> Note that this wasn't included in Red Hat Linux 7... it's been done
> since then, and I don't remember doing it myself (which of course
> doesn't mean I didn't do it :) - it might have been done for the S/390
> port, by the people working on that.

A non-conditional version (the conditional is my change) was included as
far back as RedHat 6.2.
> For most apps, it's just a question of configure working vs. configure
> failing on IA64 (there is no "tuning" as such, my choice of words
> wasn't too good). There may be something similar for S/390.

Can we test both ways (after your current project is done)?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: RPMS for 7.1beta3 being uploaded.

From
Karl DeBisschop
Date:
(Sorry of this double posts - I'm having alias troubles on the
list.)

Peter Eisentraut wrote:
> 
> Lamar Owen writes:
> 
> > Ok, I have a first set of 7.1beta3 RPMs uploading now.  These RPMs pass
> > regression on my home RedHat 6.2 machine, which has all locale environment
> > variables disabled (/etc/sysconfig/i18n deleted and a reboot).
> 
> Some thoughts:

snip

> | -#!/usr/local/bin/perl -w
> | +#!/usr/bin/perl -w
> (and more of these for Python)
> 
> I think this should be fixed to read
> 
> #! /usr/bin/env perl
> 
> Any comments?

What assurance do you have that 'env' is in /usr/bin? Linux FHS
(http://www.pathname.com/fhs/2.1/fhs-4.2.html) says that when perl
is in some location other than /usr/bin, then symlinks should be
provided to /usr/bin/perl. You don't have this assurance with
/usr/bin/env. Maybe there are some unices that do not have perl in
/usr/bin - but maybe there are unices that put 'env' into /bin
instead of /usr/bin. If you follow the current FHS, /usr/bin/perl
may be better -- but I'm not sure if that is entirely true of the
real world of linux boxes out there.

> | # copy over the includes needed for SPI development.
> | pushd src/include
> | /lib/cpp -M -I. -I../backend executor/spi.h | \
> |         xargs -n 1| \
> |         grep \\W| \
> |         grep -v ^/| \
> |         grep -v spi.o | \
> |         grep -v spi.h | \
> |         sort | \
> |         cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql
> 
> I think the standard installed set of headers is sufficient.

I haven't installed the RPM yet. But I dissent unless things have
changed from 7.0 in that respect. I copmile against executor/spi.h,
based on the examples in the docs. Should I be using something else?
(I'll have to go look at the 7.1 source, but I just wanted to
register at least some comfusion, if not dissent) 

-- 
Karl DeBisschop              kdebisschop@alert.infoplease.com
Learning Network/Reference   http://www.infoplease.com
Netsaint Plugin Developer    kdebisschop@users.sourceforge.net


Re: RPMS for 7.1beta3 being uploaded.

From
Karl DeBisschop
Date:
Peter Eisentraut wrote:
> 
> Lamar Owen writes:
> 
> > Ok, I have a first set of 7.1beta3 RPMs uploading now.  These RPMs pass
> > regression on my home RedHat 6.2 machine, which has all locale environment
> > variables disabled (/etc/sysconfig/i18n deleted and a reboot).
> 
> Some thoughts:

snip

> | -#!/usr/local/bin/perl -w
> | +#!/usr/bin/perl -w
> (and more of these for Python)
> 
> I think this should be fixed to read
> 
> #! /usr/bin/env perl
> 
> Any comments?

What assurance do you have that 'env' is in /usr/bin? Linux FHS
(http://www.pathname.com/fhs/2.1/fhs-4.2.html) says that when perl
is in some location other than /usr/bin, then symlinks should be
provided to /usr/bin/perl. You don't have this assurance with
/usr/bin/env. Maybe there are some unices that do not have perl in
/usr/bin - but maybe there are unices that put 'env' into /bin
instead of /usr/bin. If you follow the current FHS, /usr/bin/perl
may be better -- but I'm not sure if that is entirely true of the
real world of linux boxes out there.

> | # copy over the includes needed for SPI development.
> | pushd src/include
> | /lib/cpp -M -I. -I../backend executor/spi.h | \
> |         xargs -n 1| \
> |         grep \\W| \
> |         grep -v ^/| \
> |         grep -v spi.o | \
> |         grep -v spi.h | \
> |         sort | \
> |         cpio -pdu $RPM_BUILD_ROOT/usr/include/pgsql
> 
> I think the standard installed set of headers is sufficient.

I haven't installed the RPM yet. But I dissent unless things have
changed from 7.0 in that respect. I copmile against executor/spi.h,
based on the examples in the docs. Should I be using something else?
(I'll have to go look at the 7.1 source, but I just wanted to
register at least some comfusion, if not dissent) 

-- 
Karl DeBisschop                       
kdebisschop@alert.infoplease.com
Learning Network Reference             http://www.infoplease.com
Netsaint Plugin Developer             
kdebisschop@users.sourceforge.net


Re: RPMS for 7.1beta3 being uploaded.

From
Peter Eisentraut
Date:
Lamar Owen writes:

> Likewise, Peter, I'm sure that from your point of view you have good
> reasons -- I'd like to see them as well, for the same reasons as I'd
> like to see Trond's.

Two points of view here:

1.  The config.* files were specifically updated because the old ones did
not recognize certain Linux(!) setups correctly.  This probably affects
all config.*'s before August 2000.  This will simply cause the build to
fail.

2.  If you use the %{configure} macro then this will be pointless because
that macro selects the host system type itself:

| %configure \
| CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
| CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
| FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
| %{?__libtoolize:[ -f configure.in ] && %{__libtoolize} --copy --force} ; \
| ./configure %{_target_platform} \\\
...

(This is subtly wrong as well, but that's something for the RPM folks to
deal with.)

So in short, don't do it.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/