FAQ
[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

Search Discussions

  • Tom Lane at Jul 8, 1999 at 3:39 pm

    Lamar Owen 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
  • Lamar Owen at Jul 8, 1999 at 3:45 pm

    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
  • Tom Lane at Jul 8, 1999 at 5:06 pm

    Lamar Owen 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
  • Lamar Owen at Jul 8, 1999 at 6:32 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 8, '99 at 2:46p
activeJul 8, '99 at 6:32p
posts5
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Lamar Owen: 3 posts Tom Lane: 2 posts

People

Translate

site design / logo © 2022 Grokbase