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-40457-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; Sat, 3 Apr 2010 21:06:03 +0000 (UTC)
Received: by fxm4 with SMTP id 4so1249746fxm.26
for <gentoo-dev@lists.gentoo.org>; 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 <reavertm@gmail.com>
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: <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
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