Thread: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0]
[a possible answer to the RedHat 6.0 rpm -ba on Thomas' new src.rpm] Jeff Johnson wrote: >Lamar Owen wrote: > > The error is manifested as a "bad exit status" after doing the > > recursive chgrp and before doing the recursive chmod of %setup. > Hmmm, I think I know this one. > > Rpm attempts to control for the behavior of tar when run by root > by dooing chown/chgrp/chmod -R. All would be well, except that > chgrp, when presented with a dangling symlink returns a non-zero > return code which causes the build to crap out. > > There are two approaches to a fix: > > 1) Take the dangling (i.e. the target of the symlink doesn't exist) > symlink out of the postgres tar ball. > > 2) Don't attempt the chgrp while building. You can nuke the macro > %_fixgrp in /usr/lib/rpm/macros. You can also add > %undefine _fixgrp > just before the %setup in the postgres spec file. However, you will > need to use the just released rpm-3.02 if you want to do the %undefine > successfully. > > Please post this wherever is appropriate. > > 73 de Jeff > > -- > Jeff Johnson ARS N3NPQ > jbj@redhat.com (jbj@jbj.org) > Chapel Hill, NC Ok, where does the tarball have a dangling symlink.... There are four symlinks in the tarball: [root@utility postgresql-6.5]# find -type l -print ./src/interfaces/odbc/port ./src/interfaces/odbc/makefiles ./src/interfaces/odbc/template ./src/interfaces/odbc/config.h [root@utility postgresql-6.5]# ls -lR|grep lrwxrwxrwx lrwxrwxrwx 1 root root 24 Jul 8 10:18 config.h -> ../.././inclu de/config.h lrwxrwxrwx 1 root root 17 Jul 8 10:18 makefiles -> ../.././make files lrwxrwxrwx 1 root root 20 Jul 8 10:18 port -> ../.././include/p ort lrwxrwxrwx 1 root root 16 Jul 8 10:18 template -> ../.././templ ate [root@utility postgresql-6.5]# cd src/interfaces/odbc [root@utility odbc]# ls ../../. DEVELOPERS config.guess install-sh test GNUmakefile.in config.sub interfaces tools Makefile configure lextest tutorial Makefile.global.in configure.in makefiles utils Makefile.shlib corba man win32 backend data pl win32.mak bin include template Hmmm... seems that config.h and port do not exist -- voila! The dangling symlinks. Can empty port and config.h files be shipped, or will that break configure (which is what I'm assuming creates these files?)? The 6.5-1.beta1 spec file from rawhide handles this using the second method, although it is incorrectly labeled as being a sparc/alpha fix: ----from postgresql.spec, from ftp://rawhide.redhat.com/SRPMS/SRPMS/postgresql-6.5-1.beta1.src.rpm----- # XXX work around sparc/alpha dangling symlink problem %undefine _fixgroup ----------------------------- Which is why my rpms, derived from this spec file, built on 6.0, while Thomas' src.rpm, not derived from this spec file and built on 5.2, didn't build on 6.0. So, there are two possibilities: 1.) Eliminate the dangling symlinks. 2.) Put the _fixgroup kludge in place in the production SRPM. HOWEVER, this ONLY works with rpm >= 3.0.x -- which means a RH 5.2 system running rpm 2.5 won't build it -- but we're supposed to update our rpm version anyway. Thomas? And, thanks, Jeff! Lamar Owen WGCR Internet Radio KF4MYT
Lamar Owen <lamar.owen@wgcr.org> writes:
> Ok, where does the tarball have a dangling symlink....
> There are four symlinks in the tarball:
> [root@utility postgresql-6.5]# find -type l -print
> ./src/interfaces/odbc/port
> ./src/interfaces/odbc/makefiles
> ./src/interfaces/odbc/template
> ./src/interfaces/odbc/config.h
> ... So, there are two possibilities:
> 1.) Eliminate the dangling symlinks.
> 2.) Put the _fixgroup kludge in place in the production SRPM.
Those symlinks should not be in the distribution; they should be
created during "configure", which also creates the files/dirs they
point to. Unfortunately they were not getting removed by "make
distclean", so they are present in the 6.5 tarball.
I have fixed "make distclean" to remove them, and that fix will be in
6.5.1, but Thomas evidently built from the 6.5 tarball.
regards, tom lane
Tom Lane wrote: > Lamar Owen wrote: > > 1.) Eliminate the dangling symlinks. > Those symlinks should not be in the distribution; > I have fixed "make distclean" to remove them, and that fix will be in > 6.5.1, but Thomas evidently built from the 6.5 tarball. Ah, this is the Right Thing to do. So, the SRPM spec file should not be kludged to work around them for the 6.5.1 release -- but, to build 6.5 from pristine sources (RedHat policy), the "%undefine _fixgroup" hack should be retained, to build under rpm 3.0.2, unless a patch that removes those files is packaged with the 6.5 SRPM/RPMS. Thanks Tom. Lamar Owen WGCR Internet Radio
Lamar Owen <lamar.owen@wgcr.org> writes:
> Ah, this is the Right Thing to do. So, the SRPM spec file should not be
> kludged to work around them for the 6.5.1 release -- but, to build 6.5
> from pristine sources (RedHat policy), the "%undefine _fixgroup" hack
> should be retained, to build under rpm 3.0.2, unless a patch that
> removes those files is packaged with the 6.5 SRPM/RPMS.
There are several other bugfixes over 6.5 in the RPM already, so I
see no good reason not to just remove those four symlinks; it certainly
seems cleaner than kluging the RPM script...
regards, tom lane
Tom Lane wrote: > There are several other bugfixes over 6.5 in the RPM already, so I > see no good reason not to just remove those four symlinks; it certainly > seems cleaner than kluging the RPM script... > regards, tom lane Yes, that's quite true. Speaking of the rpms, I have just found a few issues that my other testing had not found. Specifically: * The data necessary to initdb is in postgresql-devel, not postgresql-server (the files in /usr/lib/pgsql, specifically the bki sources); * There are no static libraries in postgresql-devel (libpq.a, et al -- these are normally located in /usr/lib) * IMHO, a warning should be printed about proper updgrade procedure -- rpm -U just simply won't work as the rpms (and postgresql) are currently implemented -- and, unfortunately, the rpm -Uvh style is the default method for most users, as well as RedHat version updates, from 5.2 to 6.0, for example. As far as enhancements go, the postgresql-server rpm could (not necessarily should) check to see if a database structure exists in /var/lib/pgsql (if so, move it out of the way), and perform an initdb. Where this comes into play is when upgrading postgresql versions using rpm -- the rpm uninstall does not blow away the whole PGDATA/base tree -- in fact, it leaves _everything_ there. So, to upgrade, you must either rm -rf the tree or mv it out of the way -- preferably before doing an initdb. What IS the right way to do this in an automated fashion? Currently, to upgrade via rpm (on a box running SysV init, such as RedHat), you must do the following: 1.) as postgres, pg_dumpall 2.) as postgres, backup pg_hba.conf 3.) as root, rpm -e all-old-postgresql-rpms (found using rpm -qa|grep postgres) (automateable -- rpm -qa|grep postgresql|xargs rpm -e (check that xargs syntax...)) 4.) as root, blow away the /var/lib/pgsql tree, taking care not to blow away your backup 5.) as root, rpm -i select-new-postgresql-rpms 6.) as postgres, initdb --pglib=/usr/lib/pgsql --pgdata=/var/lib/pgsql 7.) as root, Edit /etc/rc.d/init.d/postgresql as needed (to add -i, FE) (to automate this, simply include -i by default, or give user a choice, and sed away...) 8.) as root, start postmaster (/etc/rc.d/init.d/postgresql start) 9.) as postgres, psql -e template1 < pg_dumpall-backup-from-step-1 10.) as postgres, restore pg_hba.conf 11.) Restart production tasks, after testing. Have I left anything out? Is it even desireable to automate this? (In my case, I'm going to build a script to keep around to do this...) Lamar Owen WGCR Internet Radio