From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 12:36:52 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 0BE9416A41F for ; Wed, 21 Dec 2005 12:36:52 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427FB43D4C for ; Wed, 21 Dec 2005 12:36:50 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp132-74.lns2.adl2.internode.on.net [59.167.132.74]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBLCah1g084493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 21 Dec 2005 23:06:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 21 Dec 2005 23:06:35 +1030 User-Agent: KMail/1.8.3 References: <43A266E5.3080103@samsco.org> <200512180107.03841.Chris@lainos.org> <20051221100944.GA54932@uk.tiscali.com> In-Reply-To: <20051221100944.GA54932@uk.tiscali.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1524423.b3c9pLnKG7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512212306.36473.doconnor@gsoft.com.au> X-Spam-Score: 0 () SUBJECT_EXCESS_QP X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: Chris Gilbert , Brian Candler 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 12:36:52 -0000 --nextPart1524423.b3c9pLnKG7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 21 Dec 2005 20:39, Brian Candler wrote: > I recently tried to upgrade Mozilla from 1.0.7 to the current ports versi= on > (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 i= ts > 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. In an ideal world this would all Just Work (tm). Unfortunately, developers don't have infinite resources so you experience=20 problems like you are seeing. It doesn't help that there is almost no binary compatibility between variou= s=20 releases of libraries (GNOME is really good for doing this in my experience= ). > So, if the new Mozilla port really requires the newest version of gtk, th= en > 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. I think the reason it isn't the default is because it pollutes your disk wi= th=20 multiple copies of things that may not be necessary. In a lot of cases it=20 will cause weird errors (eg one binary ends up with more than one version o= f=20 a library linked to it at run time because its dependents weren't all=20 upgraded) > 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 ru= ns > 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) I don't see how this can fix the problem where you have a program that depe= nds=20 on 2 libraries and each of those depend another library. If they are linked= =20 to 2 different versions of that 3rd library you can get very odd behaviour. This *is* an annoying problem, but the solutions are far from simple.. (Lots more man power would help) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1524423.b3c9pLnKG7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDqUxU5ZPcIHs/zowRAqSHAKCH+LZXoXxRfWeqD8vBty1+Ql+3TwCghq8t dgpZKgG+Svaup9/LebISUwA= =wyNX -----END PGP SIGNATURE----- --nextPart1524423.b3c9pLnKG7--