Re: (A) native Windows port

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