[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

Thu, 08 Jul 1999 10:44:39 -0400
Lamar Owen <lamar.owen@wgcr.org>
[Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0]
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

Thu, 08 Jul 1999 11:38:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0] 
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

Thu, 08 Jul 1999 11:43:51 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0]
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

Thu, 08 Jul 1999 13:05:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0] 
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

Thu, 08 Jul 1999 14:30:33 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0]