From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Nyg4k-0000rK-Dw for garchives@archives.gentoo.org; Mon, 05 Apr 2010 06:46:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AE7DEE0A45; Mon, 5 Apr 2010 06:46:19 +0000 (UTC) Received: from mail-pv0-f181.google.com (mail-pv0-f181.google.com [74.125.83.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 4729DE0992 for ; Mon, 5 Apr 2010 06:46:08 +0000 (UTC) Received: by pvg16 with SMTP id 16so1425544pvg.40 for ; Sun, 04 Apr 2010 23:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=L7cB5tOiRUJCcL4wNfuAzVW3dOMYRGxe3+JYm2ko0fg=; b=jIo71Rp8E//Qgw0mZ1y+ObPbeConPEwsU8/j9ZflL6XNZm7nJPSik17WQwA8QpxZj0 dobtyPCAQeNINoWHEJhT6DoS9+lMKJ5vwUZsWL0GJBBDjgjE+EiPsK4oYuENr9MWjj8q KMlZf85SkXSHE4QRbB22UClKHY59VIYWL7D2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=L2UvMa+8N/4uIW6MT5G/epPD5d4H3hzm5hGmYqaDLTLTKxmVj8PT9yXn3UUCyAECm+ kAR/I+rKjtIpHeQYeeZJn1e+fQBcw3JXesNns0JhqLrsTdnLV8qn2wWs56s4ebqUqYCh epJSwzsYsUBQkwy3TXOaDNOsMOkq0w2wZg5/w= Received: by 10.114.4.40 with SMTP id 40mr4197150wad.3.1270449967644; Sun, 04 Apr 2010 23:46:07 -0700 (PDT) Received: from smtp.gmail.com (c-67-171-128-62.hsd1.wa.comcast.net [67.171.128.62]) by mx.google.com with ESMTPS id 23sm1358847pzk.2.2010.04.04.23.46.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Apr 2010 23:46:06 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Sun, 04 Apr 2010 23:44:11 -0700 Date: Sun, 4 Apr 2010 23:44:11 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries Message-ID: <20100405064411.GD27486@hrair> References: <201004031238.18500.reavertm@gmail.com> <201004032305.41374.reavertm@gmail.com> <1270395197.1230.89.camel@localhost> <201004050816.42409.reavertm@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bjuZg6miEcdLYP6q" Content-Disposition: inline In-Reply-To: <201004050816.42409.reavertm@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 853e256a-46a6-4f2a-94ae-b2c793b1b4ed X-Archives-Hash: 6853221d7794b82c0577e94a10df75a6 --bjuZg6miEcdLYP6q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote: > Unconditionally removing libraries (instead of preserving them) and makin= g=20 > their reverse runtime dependencies reinstalled is unacceptable because=20 > "emerge" process involving multiple packages is not atomic. Simple as tha= t. > Is this what you suggest? Correct me if I'm wrong: > 1. Users wants to uninstall or reinstall package, we let him do it provid= ed=20 > reverse runtime dependencies are satisfied afterwards. Let's say he wants= to=20 > upgrade expat. > 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and run= time=20 > reverse deps will still be satisfied when we upgrade. > 3. Expat has been upgraded sucessfully, > 4a. "emerge" discovers reverse runtime dependencies are broken and it sta= rts=20 > to rebuild them, then it bails out due to error ld: libexpat.so. not= =20 > found. Because step 3 cannot be rolled back (no atomicy) - game over. > or > 4b. "emerge does not discover those and does nothing. python is broken so= =20 > emerge cannot be used anymore. Game over This is called 'nondeterministic resolution'- known issue also w/=20 proposals of that sort. Pretty much everytime someone proposes it as a solution, it gets=20 smacked down by most folk since an emerge -p invocation that is a=20 single pkg upgade shouldn't be able to go rebuild your entire world. The alternative is a slotted ABI var- basically a counter (although it=20 doesn't have to be) w/in ebuilds themselves to indicate if they're=20 carrying a new ABI from upstream for that slotting. For example,=20 you've got EXPAT merged w/ ABI=3D2, version 2.0. version 2.0.1, for=20 whatever reason, breaks ABI- thus v2.0.1 in the tree is ABI=3D2.0.1 (or=20 3, as said it's an arbitrary value). Via that, the resolver can see that a rebuild is necessary and plan a=20 rebuild of all consumers (whether NEEDED based or revdep). Note=20 preserve-lib would be rather useful here- specifically holding onto=20 the intermediate lib while doing rebuilding. This however breaks down=20 a bit when the ABI change is in reverse of normal versioning. Usually whenever I've floated this idea, it's gotten smacked down by=20 devs due to the extra work it may entail- someone doing an experiment=20 on this would be rather useful (someone with a tinderbox=20 specifically). ~harring --bjuZg6miEcdLYP6q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAku5hrsACgkQsiLx3HvNzgcfHwCdFg+r8WzerM1IenROoxg9RUQd ipIAniPXnFGH6Tu/t7oORK7+OLz0dqyD =9pKu -----END PGP SIGNATURE----- --bjuZg6miEcdLYP6q--