HEADS UP: xorg upgrade plans

[Kris Kennaway]

On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote:
> On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway <kris at obsecurity.org>  
> wrote:
> 
> >On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote:
> >
> >>>No, at a minimum I am not comfortable recommending its use until it
> >>>saves old shared libraries across updates (I sent you email about this
> >>>a while ago), which is a vital safety and robustness mechanism.
> >>
> >>I am one of people that dislike this and it is not required to get build
> >>function. ;-) I think this option should be disable by default, because
> >>put stuff in lib/compat/pkg hides the problems. Also:
> >
> >No, it is required when dealing with shared library bumps (which
> >happen about once a week).  Otherwise all of the installed ports using
> >the library break if the new library build fails.  Talk to Brooks
> >about how annoying this is with e.g. gettext.
> 
> portmaster has a feature to backup the old package before the upgrade. I  
> think it is better than put in lib/compat/pkg. When I used portupgrade and  
> I always have lib/compat/pkg disabled until I switched to portmaster. I  
> never have that problem when ports tree is flexible enough to downgrade  
> and wait until someone fix it.

Well, is this feature enabled by default and does it completely back
out the upgrade if it fails?  I may be wrong, but I doubt it is going
to do a complete recursive backout of the upgrade if e.g. one of the
ports depending on the new library fails to build after the library
was updated.  If it just restores the old version of this port then it
will be restoring a nonfunctional port, since it links to the version
of the library that was already deleted.

The issue is about providing seat-belts for our users who just want
failed upgrades not to destroy their system.  Even if you think that
backing up the package is a better solution than preserving the shared
libraries, it seems to me that portmaster still falls short here
because it doesn't provide a rollback mechanism to restore the system
to a working state when an upgrade fails.

> >I dispute the correctness of this entry.  The old libraries in
> >lib/compat/pkg are not linked to directly by new builds.  The only
> >situation in which something might end up being linked to 2 versions
> >of the library is if it pulls in a library dependency from an existing
> >port that is still linked to the old library.  In this situation the
> >build would be broken with or without lib/compat/pkg (in the latter
> >case, you have an installed port linked to a library that is entirely
> >missing, so that port will be nonfunctional).
> >
> >Kris

I guess your silence means you agree with me here :)

Kris