Re: RPMS for 7.1beta3 being uploaded.

Поиск
Список
Период
Сортировка
От Lamar Owen
Тема Re: RPMS for 7.1beta3 being uploaded.
Дата
Msg-id 3A63627C.A2B56B37@wgcr.org
обсуждение исходный текст
Ответ на Re: RPMS for 7.1beta3 being uploaded.  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: RPMS for 7.1beta3 being uploaded.  (teg@redhat.com (Trond Eivind Glomsrød))
Re: RPMS for 7.1beta3 being uploaded.  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: RPMS for 7.1beta3 being uploaded.  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: subselect bug?
Следующее
От: bpalmer
Дата:
Сообщение: $PGDATA/base/???