[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
Import Notes
Reply to msg id not found: YourmessageofThu08Jul1999104439-04003784B957.FC6CEE10@wgcr.org | Resolved by subject fallback
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
Import Notes
Reply to msg id not found: YourmessageofThu08Jul1999114351-04003784C737.C440A08C@wgcr.org | Resolved by subject fallback
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