From owner-freebsd-ports@FreeBSD.ORG Mon May 7 22:26:46 2007 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA15F16A401; Mon, 7 May 2007 22:26:46 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B1EE313C44C; Mon, 7 May 2007 22:26:46 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 194D91A4DC8; Mon, 7 May 2007 15:27:27 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D5F4B51344; Mon, 7 May 2007 18:26:45 -0400 (EDT) Date: Mon, 7 May 2007 18:26:45 -0400 From: Kris Kennaway To: Jeremy Messenger Message-ID: <20070507222645.GB57768@xor.obsecurity.org> References: <20070502193159.GB42482@xor.obsecurity.org> <463F7236.4080108@FreeBSD.org> <20070507184231.GA50639@xor.obsecurity.org> <20070507201448.GA52651@xor.obsecurity.org> <20070507204414.GA53358@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: ports@freebsd.org, Doug Barton , Kris Kennaway Subject: Re: HEADS UP: xorg upgrade plans X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2007 22:26:47 -0000 On Mon, May 07, 2007 at 05:02:52PM -0500, Jeremy Messenger wrote: > On Mon, 07 May 2007 15:44:14 -0500, Kris Kennaway > 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 > >>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