HEADS UP: xorg upgrade plans

[Kris Kennaway]

On Mon, May 07, 2007 at 05:02:52PM -0500, Jeremy Messenger wrote:
> On Mon, 07 May 2007 15:44:14 -0500, Kris Kennaway <kris at obsecurity.org>  
> wrote:
> 
> >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?
> 
> Default.. I am not sure, but I just know that there has option and I have  
> disable backup in my configure. As for the second question, no, I don't  
> think it doesn't. The users have to do it by manual to reinstall it.  
> Correct me if I am wrong. [read other replied from Brooks] Brooks said  
> that pkg_create has problems that need to be solve. I guess, it has shoot  
> this down.
> 
> >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
> 
> You are right, it doesn't. I don't think it will be easy to add this  
> feature.

Yes, me either.  But you've got to either do one thing or the other.

> >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.
> 
> I think it is rare and will get fix quickly (most of time). It shows real  
> problem rather than hide it by using old library. This is what I like it.  
> It helps our package to be more stable in both build and runtime.

This is the attitude of a ports developer.  The attitude of a user is
"what the heck?  I just wanted to update my ports and now my desktop
is completely unusable and I have to wait an unspecified time for
someone else to tell me how to fix it."

> >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,
> 
> Yes, I think backing up is a better solution. For example, when library  
> has been bumped but also the plugins, format of configure file or whatever  
> have been complete revamp. The lib/compat/pkg won't help and the backup  
> will.

FYI, portupgrade does both, and therefore catches both failure modes.

> As Brooks said, 'There are other possible solutions, but saving copied of  
> libraries seems to be the accepted one at the moment.' The 'accepted' is  
> opposite for me. It's why I am suggesting to disable it by default if  
> someone is going to add it in portmaster for any users that don't want or  
> have time to help. ;-)

I don't control what Doug chooses to do with his software, but I can
evaluate the results of those choices and how they impact the utility
of his software for non-technical users of FreeBSD.

> >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 :)
> 
> Yeah, I guess and unsure at the same time since I didn't write this entry.  
> :-)

OK.

Kris