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 <gentoo-dev+bounces-40550-garchives=archives.gentoo.org@lists.gentoo.org>) id 1NymLW-0002uK-0V for garchives@archives.gentoo.org; Mon, 05 Apr 2010 13:28:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 68218E0A62; Mon, 5 Apr 2010 13:28:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5FD3FE09F9 for <gentoo-dev@lists.gentoo.org>; Mon, 5 Apr 2010 13:27:41 +0000 (UTC) Received: from [192.168.0.103] (100-163.78-83.cust.bluewin.ch [83.78.163.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 3ED911B406C for <gentoo-dev@lists.gentoo.org>; Mon, 5 Apr 2010 13:27:40 +0000 (UTC) Subject: Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries From: Tiziano =?ISO-8859-1?Q?M=FCller?= <dev-zero@gentoo.org> To: gentoo-dev@lists.gentoo.org In-Reply-To: <20100405064411.GD27486@hrair> References: <201004031238.18500.reavertm@gmail.com> <201004032305.41374.reavertm@gmail.com> <1270395197.1230.89.camel@localhost> <201004050816.42409.reavertm@gmail.com> <20100405064411.GD27486@hrair> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-qAzrGc2919w0sQv+RfOH" Organization: Gentoo Date: Mon, 05 Apr 2010 15:27:34 +0200 Message-ID: <1270474054.30670.4.camel@localhost> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.28.3.1 X-Archives-Salt: 926c22d2-6ca5-4152-ab65-48f9059f2bdf X-Archives-Hash: d0149424cbe413c8d77d36cfec49a9bc --=-qAzrGc2919w0sQv+RfOH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Sonntag, den 04.04.2010, 23:44 -0700 schrieb Brian Harring: > On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote: > > Unconditionally removing libraries (instead of preserving them) and mak= ing=20 > > their reverse runtime dependencies reinstalled is unacceptable because=20 > > "emerge" process involving multiple packages is not atomic. Simple as t= hat. > > Is this what you suggest? Correct me if I'm wrong: > > 1. Users wants to uninstall or reinstall package, we let him do it prov= ided=20 > > reverse runtime dependencies are satisfied afterwards. Let's say he wan= ts to=20 > > upgrade expat. > > 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and r= untime=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 s= tarts=20 > > to rebuild them, then it bails out due to error ld: libexpat.so.<sth> n= ot=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 >=20 > This is called 'nondeterministic resolution'- known issue also w/=20 > proposals of that sort. >=20 > 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. >=20 > 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). >=20 > 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. No, it doesn't help since you may have the same problems some people try to solve in this thread. > This however breaks down=20 > a bit when the ABI change is in reverse of normal versioning. How so? Such a var should just specify the ABI and the PM only has to check whether it changed from one PVR to the other. The "how" is completely irrelevant. --=20 Tiziano M=C3=BCller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-zero@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 --=-qAzrGc2919w0sQv+RfOH Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKbjCCBTMw ggMboAMCAQICAwg/VjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDAyMjIxMDQzMzBaFw0x MjAyMjIxMDQzMzBaMD0xFzAVBgNVBAMUDlRpemlhbm8gTfxsbGVyMSIwIAYJKoZIhvcNAQkBFhNk ZXYtemVyb0BnZW50b28ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1LnPwwQ2 3O3zXpqQ2p8WtdpOnQDeyUja0gn+BSULJ8uZ6ro6Xg9cUZdOVStm6SLjAU82fSVsEsvDw1u2plf1 qTtLkXRtnyaJjFhGC27/MR/tQqOR5eC2qWbwQuB2B+wS/9hHoqjfLAIVksqwDfFjCNz1QEj+EyAl O5LuwRWs7Cwmk37wXkaCW6vEzmATJhN0cBXcR5rKJv0dmvLE66NX5MqXfQQ4kSFMSIaFbhc/+Vix b92hF+KhfG8C0PMUFvCzToFYgU+uEL9kvmUfa8MkVzaicWmsnycZ+aywZrBfgJqB50FCANSq2gQ1 8KnajvMc3lAY5njvJ9S1i0SZQGw7hwIDAQABo4H/MIH8MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4 QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8g aHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYB BAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw AYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAeBgNVHREEFzAVgRNkZXYtemVyb0BnZW50b28ub3Jn MA0GCSqGSIb3DQEBBQUAA4ICAQCu3CflSuep7/s1rJnx/DOwVPIPzytTmfJ++L543zniENTsOrvB MGKv0U0QXcRxnZrV5lboJ2V6VK7lEUSGl54fiaM+ixxv+L2r1FJYkulctQIcJElb1Y2D0tWVmcpF NPG9dCSnmYsZlK3YMJsieYD1ifWNs3achZFxIYBMapo4vTILS8NhD8OyfZEefFTRthTDn25dlhBK qmTZJZqA2PEpy5BIJ+T0Ico7IaoBWmBSsFeJ1ytGAFtFTpWMwdrbSgl9tR2gTHtheC0il7cE6Ets F4h3NeMkDjCmuo8SsmivLh0baw2aZPz4ka3iFjMFA6ruts7yuOj03XTwWpCC7XthexysmcafO72Y QRXuddKeCbFNROJ7DBy5kwcXly3e/lgaPpGXV75VU1LeTPmVRl6tI2jaQMjSWiMpjM0hFm2q/mCQ Kiz6/+4La9aN5J7ov5X+RMbpPcKGo8q3hrInD6rqGRCPi/7Md5c0WebwYFnAB34S7RJS4y6bR6hl l1pNQcOE6heDf1EkzkXw88Z/BvxLBgE8EwSL5GD5ZA27udAlgWsc4NVEx/lheDdc1vPb+C45OFkb ZsBne4wijsNccZlVtqpkm++6QII6H2G9a8Pef+/5An+3jW7qNfYRDFGa+uGqBDD6yUkwTIOhajtl qx5ZQU2z5g5CBKqOuA74CYRR7TCCBTMwggMboAMCAQICAwg/VjANBgkqhkiG9w0BAQUFADB5MRAw DgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0 Lm9yZzAeFw0xMDAyMjIxMDQzMzBaFw0xMjAyMjIxMDQzMzBaMD0xFzAVBgNVBAMUDlRpemlhbm8g TfxsbGVyMSIwIAYJKoZIhvcNAQkBFhNkZXYtemVyb0BnZW50b28ub3JnMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA1LnPwwQ23O3zXpqQ2p8WtdpOnQDeyUja0gn+BSULJ8uZ6ro6Xg9c UZdOVStm6SLjAU82fSVsEsvDw1u2plf1qTtLkXRtnyaJjFhGC27/MR/tQqOR5eC2qWbwQuB2B+wS /9hHoqjfLAIVksqwDfFjCNz1QEj+EyAlO5LuwRWs7Cwmk37wXkaCW6vEzmATJhN0cBXcR5rKJv0d mvLE66NX5MqXfQQ4kSFMSIaFbhc/+Vixb92hF+KhfG8C0PMUFvCzToFYgU+uEL9kvmUfa8MkVzai cWmsnycZ+aywZrBfgJqB50FCANSq2gQ18KnajvMc3lAY5njvJ9S1i0SZQGw7hwIDAQABo4H/MIH8 MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0 ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcG CCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIG CCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAeBgNVHREE FzAVgRNkZXYtemVyb0BnZW50b28ub3JnMA0GCSqGSIb3DQEBBQUAA4ICAQCu3CflSuep7/s1rJnx /DOwVPIPzytTmfJ++L543zniENTsOrvBMGKv0U0QXcRxnZrV5lboJ2V6VK7lEUSGl54fiaM+ixxv +L2r1FJYkulctQIcJElb1Y2D0tWVmcpFNPG9dCSnmYsZlK3YMJsieYD1ifWNs3achZFxIYBMapo4 vTILS8NhD8OyfZEefFTRthTDn25dlhBKqmTZJZqA2PEpy5BIJ+T0Ico7IaoBWmBSsFeJ1ytGAFtF TpWMwdrbSgl9tR2gTHtheC0il7cE6EtsF4h3NeMkDjCmuo8SsmivLh0baw2aZPz4ka3iFjMFA6ru ts7yuOj03XTwWpCC7XthexysmcafO72YQRXuddKeCbFNROJ7DBy5kwcXly3e/lgaPpGXV75VU1Le TPmVRl6tI2jaQMjSWiMpjM0hFm2q/mCQKiz6/+4La9aN5J7ov5X+RMbpPcKGo8q3hrInD6rqGRCP i/7Md5c0WebwYFnAB34S7RJS4y6bR6hll1pNQcOE6heDf1EkzkXw88Z/BvxLBgE8EwSL5GD5ZA27 udAlgWsc4NVEx/lheDdc1vPb+C45OFkbZsBne4wijsNccZlVtqpkm++6QII6H2G9a8Pef+/5An+3 jW7qNfYRDFGa+uGqBDD6yUkwTIOhajtlqx5ZQU2z5g5CBKqOuA74CYRR7TGCAzMwggMvAgEBMIGA MHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAG A1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBj YWNlcnQub3JnAgMIP1YwCQYFKw4DAhoFAKCCAYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTAwNDA1MTMyNzMxWjAjBgkqhkiG9w0BCQQxFgQUgN8YIm8QWw4z4XyW 97+Ak/AL7ZMwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCD9WMIGTBgsqhkiG9w0BCRAC CzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCD9WMA0GCSqGSIb3DQEBAQUABIIBALnyJyAwYUK5Ob2o2h0VpLRp 4wHW/WzEAvHDydyYlt5Oege1P6t8aSsFT2FXu453/TNzzcVpHkAg2zi/akwNJkCAKhTldgv3OTCZ Jc++YGPvxMxkx8YIElelkBi+yHuvOI5AU6AKBbY1WYPgsMleXYJJpLH+W5CUnMsHAJJVKH0KNGFs qb6DuBUNFq1a0aTH/Duw7yeMem96vu9hl4pQmH/8Wcr7EbrSLB5TtDwY8msQti0zB3uKvPO/u/uS txNa0Ye7k/s+n3hctaj+F+g3bJs8g08cAVl31iLbIXpEC2WOQ7gW3y5nspygYWwyYwU+XRnu1mHr RXRZZp/NRqks1gIAAAAAAAA= --=-qAzrGc2919w0sQv+RfOH--