Обсуждение: RPMS for 7.1beta3 being uploaded.
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
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
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/
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
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
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.
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
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
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
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
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
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
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/
> > 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
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.
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/
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/
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
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
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.
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.
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
(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
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
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/