RPM restrictions (was:Re: [HACKERS] PG_UPGRADE status?)

Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > DAEMONS -- the upgrade MIGHT be running in the wicked chroot environment
> > of the RedHat installer, with its restrictive set of commands.  So, I

> chroot?  Where are you chrooted to?  It would seem from your description
> that neither the preinstall nor postinstall scripts can even see the
> /usr/local/pgsql directory tree, which would make it impossible to do
> anything --- and would be an incredibly stupid way to design an
> installer system, so I have to assume I'm misreading what you wrote.

I think you are misreading what I wrote, which is not at all surprising
-- it took me awhile to grok it.

No, during the installation of a version of RedHat Linux, the installer
(which boots off of either a floppy set or a virtual El Torito image on
CD) installs all the RPM's to the new root filesystem under chroot to
that new root filesystem.  Thus, the real root is /dev/fd0 or whatever
the El Torito image's /dev entry is.  The new root is mounted in a
directory off of the real root, and the rpm is installed with a chroot
to the new very incomplete root.  Fortunately, PostgreSQL gets 
installed down the list quite a ways, as P is after the halfway point.

To add to the confusion, there IS no /usr/local/pgsql -- RedHat has
munged the installation around to conform to the FSSTND for Linux --
meaning that the PostgreSQL binaries go in /usr/bin, the libraries go in
/usr/lib, the templates and other libraries that would ordinarily go in
PGLIB go in /usr/lib/pgsql, and PGDATA is /var/lib/pgsql.  The goal is a
read-only /usr, but they are a little ways from that. And that is OK, as
RPM keeps a database of what file belongs to what package.

> Also, if the pre/postinstall scripts cannot contact existing processes,
> then there is no hope of killing/restarting any kind of daemon process,
> not just Postgres in particular.  The restrictions you claim are there
> would make RPMs unusable for upgrading *anything* that has a
> continuously running server process.

The restrictions are only on RPM's that ship as part of the Official
Boxed Set.  RPM's are designed to be totally self-contained --
dependencies are rigorously specified (such as the PostgreSQL RPM's
dependency upon chkconfig to set the init sequence number), and
assumptions are nil.  I can do very little in the pre and post scripts
-- making an offline backup of PGDATA and the essential executables and
libraries needed to restore the old PGDATA is the extent of it.  Of
course, I then have to contend with the user who upgrades with
postmaster running.... 

To summarize: RPM's that ship as part of the RedHat Official Boxed Set
(OBS) (which PostgreSQL does), must contend with two very different
installation environments:
1.)    The chroot installer at initial operating system install time, and
its OS upgrade alter ego;
2.)    The environment of rpm -U, whether initiated by the user or by proxy
(such as AutoRPM), which is an entirely NORMAL environment where you can
do anything you want.

Other RPM's that do not ship as part of the OBS do not have the
restrictions of 1.  However, being in the OBS is a very desireable
place, as that assures that ALL RedHat users have the opportunity to use
PostgreSQL -- and, in fact, PostgreSQL is the ONLY RDBMS RedHat is
shipping, giving us tremendous exposure.

> Is Red Hat really that far out
> in left field?

If you want to call it left field, yes, they are.  RPM's are the HTML of
the package managers -- the author has little to no control over
presentation -- that is, package installation order, or, for that
matter, whether the install time scripts even get run (rpm --noscripts,
anyone...).  It is a very _different_ environment.

> chroot would generally imply that you can't see the regular /tmp dir,
> either.

The mounted root /tmp is visible BECAUSE of the chroot in the installer
-- but Bruce's suggestion of connecting to port 5432 is a better idea. 
Although, in the installer, I can't do that either... ;-(.  I guess I
need to first detect whether we're in the installer or not.  And RedHat
doesn't want me to be able to do that.  Catch 22.

Thanks -- the discussion is helping me find holes in my strategy.

Lamar Owen
WGCR Internet Radio