HEADS UP: xorg upgrade plans

[Jeremy Messenger]

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.

> 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.

> 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.

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. ;-)

> 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.  
:-)

Cheers,
Mezz

> Kris


-- 
mezz7 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team  -  FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org
http://wiki.freebsd.org/multimedia  -  multimedia at FreeBSD.org