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 по дате отправления: