From owner-freebsd-ports@FreeBSD.ORG Mon May 7 22:00:23 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 D0FEF16A400; Mon, 7 May 2007 22:00:23 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtao101.cox.net (eastrmmtao101.cox.net [68.230.240.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6E41313C44C; Mon, 7 May 2007 22:00:23 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao101.cox.net (InterMail vM.7.05.02.00 201-2174-114-20060621) with ESMTP id <20070507220023.DVWN19390.eastrmmtao101.cox.net@eastrmimpo02.cox.net>; Mon, 7 May 2007 18:00:23 -0400 Received: from mezz.mezzweb.com ([24.255.149.218]) by eastrmimpo02.cox.net with bizsmtp id wN0M1W00E4iy4EG0000000; Mon, 07 May 2007 18:00:22 -0400 Date: Mon, 07 May 2007 17:02:52 -0500 To: "Kris Kennaway" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 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> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20070507204414.GA53358@xor.obsecurity.org> User-Agent: Opera Mail/9.20 (Linux) Cc: ports@freebsd.org, Doug Barton 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:00:24 -0000 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. > 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@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org http://wiki.freebsd.org/multimedia - multimedia@FreeBSD.org