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 1NyAY2-0005Lj-Rz for garchives@archives.gentoo.org; Sat, 03 Apr 2010 21:06:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2FBD1E088A; Sat, 3 Apr 2010 21:06:26 +0000 (UTC) Received: from mail-fx0-f212.google.com (mail-fx0-f212.google.com [209.85.220.212]) by pigeon.gentoo.org (Postfix) with ESMTP id AD572E0866 for ; Sat, 3 Apr 2010 21:06:03 +0000 (UTC) Received: by fxm4 with SMTP id 4so1249746fxm.26 for ; Sat, 03 Apr 2010 14:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:disposition-notification-to :mime-version:content-type:content-transfer-encoding:message-id; bh=rDIqw3jul21hmfYuJVdN1zuVrw87Ynhr+xxQdtKLZQ0=; b=PMgaL0ClLpUznoj6gEDrsvx5aTDt2RNujTwBH8xrDSvQ9k6wg/FFfnbhq9b2qqC06F 5xvNoe9JCN6I+npgEK7v1g/KV2fZ6x1IixS73XWf5ocycURn2ZpeP6mH/0FIQpzPraJJ EHj9BVBHXjAp4HkVImtn2zb2xcnrVDGBCgtLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to :disposition-notification-to:mime-version:content-type :content-transfer-encoding:message-id; b=aSZWgEQ9mC+ILnME5HZ1E7tj8za5u5VcLPHK77MoG2NsZ5zMz5NziRU5TIT3kPCnhG ShNuEjjDMUb1pPMkwFln1ORCmuLrI2xwPcAa+rSdESbrafngwrqOpAplv06yxuBY7Pn9 8QB8Kn10vorWHnVB8R+kq5K/oVl5Df5EXSYIA= Received: by 10.223.58.20 with SMTP id e20mr3630650fah.96.1270328762898; Sat, 03 Apr 2010 14:06:02 -0700 (PDT) Received: from lebrodyl.localnet (abxa214.neoplus.adsl.tpnet.pl [83.8.250.214]) by mx.google.com with ESMTPS id 15sm7154552fxm.7.2010.04.03.14.06.00 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Apr 2010 14:06:02 -0700 (PDT) From: Maciej Mrozowski To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries Date: Sat, 3 Apr 2010 23:05:41 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.31-gentoo-r10; KDE/4.4.2; x86_64; ; ) References: <201004031238.18500.reavertm@gmail.com> <1270320703.1230.11.camel@localhost> In-Reply-To: <1270320703.1230.11.camel@localhost> 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: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201004032305.41374.reavertm@gmail.com> X-Archives-Salt: e44aafad-4d84-4a02-970c-1bed0cd65b35 X-Archives-Hash: 734d7000b879b9197890af8d44ad92bd On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote: > Shouldn't we fix that buildsystem then? Do you have an example of a > package/buildsystem that does that? "We" already do, the thing is that maybe we don't have to. https://bugs.gentoo.org/show_bug.cgi?id=3D240323 =46rom top of my head: python having issues with sys-libs/db as well as som= e=20 packages with readline. =20 > > It would indeed. Now when I think about it, moving stuff to preserved > > library dir could be just done - provided it's possible - along with > > fixing/setting DT_RPATH's in reverse runtime dependencies. This way no > > system-wide LIBRARY_PATH's would be necessary. > > Is it possible? Mike? > No, unless you somehow make sure you reserve space for this, by e.g. > setting a bogus rpath entry at buildtime. If you want to go that route, > you probably want to look at the Prefix' binutils-config wrapper that > already calls the linker with added rpath arguments. Afterwards you can > use chrpath to set it to the correct location. Will get messy with the > vdb though, but if Portage's doing it, it can probably be dealt with. Sounds messy indeed, what about hardened/SELinux/AppArmor/whatever - do the= y=20 allow such DT_RPATH operations? It should be probably also restricted for=20 binary-only packages. On Saturday 03 of April 2010 20:51:43 Tiziano M=C3=BCller wrote: > Don't fix the hack. Remove the preserve libs "feature", make the PMs > check for rdeps per default before unmerging things. This will only prevent creating orphans of uninstalled libraries, what abou= t=20 upgraded ones when SOVERSION has been bumped (the most common case)? Beside= s I=20 can already imagine PMS-related discussion regarding "make the PMs check fo= r=20 rdeps per default before unmerging things" - thx but no thx. > Slot libraries where needed, slot dep operators (EAPI 4) will help. Again, you suggest to SLOT every library that happened to bump SOVERSION. I= t's=20 unrealistic. Besides library should be slotted when it's API changes, for=20 source based distributions it's not needed for ABI changes - let's not conf= use=20 those two. Also excessive slotting increases probability of breaking librar= y=20 discovery mechanisms in various build systems (not everyone uses pkg-config= ). > And if that doesn't work out we need a separate var to give the PM a hint= =20 when API/ABI breakages happen (such that the PM knows when to re-install th= e=20 rev deps). It needs PMS amended and thus GLEP. Please submit a GLEP item for this if y= ou=20 see it fit. Anyway, as explained in OT, it's not a problem of package manager dependenc= ies=20 system but issue with broken/not smart build systems - no dependency tree=20 magic will solve this issue. =2D-=20 regards MM