Re: (A) native Windows port - Mailing list pgsql-hackers

On Wednesday 10 July 2002 04:42 pm, Jan Wieck wrote:
> Lamar Owen wrote:
> > On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
> > > The problem why this conflicts with these package managers is,
> > > because they work package per package, instead of looking at the
> > > big picture. Who said you can replace package A before running
> > > the pre-upgrade script of dependent package B?

> > The postgresql-server subpackages of
> > two versions are 'Package A' above.  There is no package B.

> Someone was talking about doing a complete OS upgrade and updating
> something the new PG release (that is scheduled for update later) needs
> but what makes the current old release not functional any more. Maybe I
> misunderstood something.

Yes, you misunderstood.  The whole release is upgraded, and its the database 
itself that breaks.  How is the package manager supposed to know you had to 
make a backup copy of an executable in order to cater to the broken upgrade 
cycle?  (Is that sarcastic enough :-)... being that you like your daily dose 
:-)).

The backup executable no longer 'belongs' to any package as far as the rpm 
database is concerned.  

Suppose the upgrade in question was from PostgreSQL 7.0.3-2 to 7.2.1-5 (the 
'-2' and '-5' are the release numbers of that particular RPMset -- a version 
number for the package independent of the upstream program).  The backend 
itself belongs to package 'postgresql-server' in both versions.  After 
checking that postinstallation dependencies will be satisfied by its actions, 
the upgrade proceeds to install postgresql-server-7.2.1-5, which has a %pre 
scriptlet that makes a copy of /usr/bin/postgres and links, along with libpq 
and pg_dump for that version, into /usr/lib/pgsql/backups (IIRC -- it's been 
a long day and I haven't checked the accuracy of that detail).  

Said %pre scriptlet runs, then rpm unpacks its payload, a cpio archive 
containing the files of the package.  /usr/bin/postgres is one of the files 
overwritten in this process.  There could be trigger scripts installed by 
other packages run at this time.  Then the %post scriptlet is run, which in 
practice creates a postgres user and group, chowns a few directories, and 
runs ldconfig to get any new shared libraries.  

Now the postgresql-server-7.0.3-2 package gets uninstalled.  First, the 
%preuninst scriptlet runs.  Note that a conditional is available to 
distinguish between an upgrade 'uninstall' and a real uninstall.  Then any 
registered triggers are run.  Then any non-overwritten files are removed, and 
the database entries for 7.0.3-2 are removed.  Finally, the %postuninst 
scriptlet runs.

You now have the new package in place.

During an OS upgrade the dependencies are finagled in such a way that the 
'satisfied dependencies' for postgresql-server-7.0.3-2, which is going to be 
replaced by postgresql-server-7.2.1-5's, won't be required any more.  Unless 
another package requires the various shared libraries the 7.0.3-2 backend 
required, those shared libraries may get 'upgraded' out of the way -- the 
scriptlets have no way of communicating to the upgrade process 'hey! hold on 
to the dependency information for postgresql-server-7.0.3-2, even though that 
package is no longer marked as being installed.'

Whew.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11