From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 10:09:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7634716A41F for ; Wed, 21 Dec 2005 10:09:50 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50B1B43D55 for ; Wed, 21 Dec 2005 10:09:49 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id CD7A3AB; Wed, 21 Dec 2005 05:10:09 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 501562518; Wed, 21 Dec 2005 05:10:08 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ep0um-000EIs-MX; Wed, 21 Dec 2005 10:09:44 +0000 Date: Wed, 21 Dec 2005 10:09:44 +0000 From: Brian Candler To: Chris Gilbert Message-ID: <20051221100944.GA54932@uk.tiscali.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> <200512180107.03841.Chris@lainos.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512180107.03841.Chris@lainos.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 10:09:50 -0000 On Sun, Dec 18, 2005 at 01:07:03AM +0100, Chris Gilbert wrote: > And that still doesn't solve the problem with desktop users who just want to > grab binaries and install them... my Wife was unlucky enough to have this > happen to her, and even though she has been using FreeBSD successfully for a > few years, it trashed her dependency tree to the point where I just had to > nuke most of her applications and recompile everything for her. (Not good!) Here here! I recently tried to upgrade Mozilla from 1.0.7 to the current ports version (1.5.something) on a FreeBSD 5.4 box. This fell over in all sorts of ways, and I ended up having to portupgrade almost everything. That then broke me in all sorts of other ways, like finding that 'unison' was upgraded and its protocol was no longer compatible with 'unison' on other systems, so they needed upgrading too. Plus I had to remember to abort the upgrade before it started rebuilding openoffice, to avoid my system becoming polluted with java... I have no problem with libraries called libgtk.so.400 or whatever, but the whole point of this scheme is that it should be possible to have multiple versions installed at the same time. So, if the new Mozilla port really requires the newest version of gtk, then it should simply go build that version of gtk and install it alongside my existing version, so all the ports linked against the older versions continue to work. Setting FORCE_PKG_REGISTER might do this, but if that works so well, why is it not the default? And then there are various flags to portupgrade / pkg_install which explicitly tell them to leave stale versions of shared libraries around, 'just in case' they are needed. > Perhaps this subject should be moved to another list and focused on what would > be a good way to create a stronger package/binary management and updating > system for FreeBSD? (That plays nicely with ports, and also handles > kernel/world/security updates) I'd like to see that. I think Dragonfly have some good ideas, like using the filesystem to build a virtual library environment on the fly. That is, when an application runs it sees a /lib directory populated with only the libraries it needs, and the exact versions of them. Extending this so that it is possible to have multiple versions of the same application (/usr/bin/foo) installed, for instant upgrade and rollback, would be even better. (I know there are existing solutions which install lots of symlinks, and some ideas can probably be taken from those too) Regards, Brian.