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?
>
> How does this create the problem? 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.
>
> Define 'the big picture' for all possible permutations of installed packages,
> please.
Got me on that. Sure, with all the possible permutations there is
allways an unsolveable dependency. What I think is, that knowing all
packages that are installed, that are to be added/removed/updated, it
would be possible to run pre-install, pre-update, pre-remove scripts for
all packages first. They have to clean up, save info and the like (dump
in our case, maybe install a new version of pg_dump runnable in the old
environment), but NOT disable functionality of any package. Second
install all binaries. Third run a second round of scripts for all
packages, finalizing the packages action.
>
> > Somehow this looks
> > like a foreign key violation to me. Oh, I forgot, RI constraints
> > are for documentation purposes only ... Greetings from the MySQL
> > documentation ;-)
>
> Is sarcasm really necessary?
Really really! I am dependent on it. If I don't get my daily dosis of
sarcasm, I become extremely ironic or sometimes cynic.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #