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-40544-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Nyfco-0004gH-4f
for garchives@archives.gentoo.org; Mon, 05 Apr 2010 06:17:40 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 611F0E0AD3;
Mon, 5 Apr 2010 06:17:25 +0000 (UTC)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158])
by pigeon.gentoo.org (Postfix) with ESMTP id DAB4DE0A80
for <gentoo-dev@lists.gentoo.org>; Mon, 5 Apr 2010 06:17:16 +0000 (UTC)
Received: by fg-out-1718.google.com with SMTP id d23so919555fga.10
for <gentoo-dev@lists.gentoo.org>; Sun, 04 Apr 2010 23:17:16 -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=U1Cpkwf4uSSUAmZlnTt7U9/dHdWtUvt4NDqBMVFRqyY=;
b=JBWNzRUP2KxSdx/GmFFnas2qtxWf2EwWMFYiyvzYDCAgFfzgiGwORn/MB3W2uipTII
CxBn88IQEU4jM+2dD8JBtSy9uiCnR6f0wt8gZhUv3qs8uYeNuN0gN6idhGmy7MPgOucX
K3ypCf2goJPmBe99A6BApAus5VKGnHkXXIQeM=
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=tdrsQ0m0/5LVjbtbSTOZXJkilJiZGIwpwQ3rDWpfYGlGTP5lkBFuYzCnoBEcTEvUQX
NEyJoTP208UysGmydfSsxF0e6oheHGZG1DmUzh4xsIMaKGgbNhs/5kpOvNbmNQOS9vnZ
H//9VWIgrf5iizZ1G/LWjYN7Zr+i3V6nSAsPU=
Received: by 10.87.49.36 with SMTP id b36mr8330548fgk.57.1270448236210;
Sun, 04 Apr 2010 23:17:16 -0700 (PDT)
Received: from lebrodyl.localnet (azu92.neoplus.adsl.tpnet.pl [83.27.158.92])
by mx.google.com with ESMTPS id 16sm7792955fxm.4.2010.04.04.23.17.14
(version=SSLv3 cipher=RC4-MD5);
Sun, 04 Apr 2010 23:17:15 -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: Mon, 5 Apr 2010 08:16:42 +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> <201004032305.41374.reavertm@gmail.com> <1270395197.1230.89.camel@localhost>
In-Reply-To: <1270395197.1230.89.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"
Message-Id: <201004050816.42409.reavertm@gmail.com>
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 4cbf2e77-81be-456d-9704-20ee9b9d82fd
X-Archives-Hash: f2339c0bee8acad412bc4961e5d90816
On Sunday 04 of April 2010 17:33:17 Tiziano M=C3=BCller wrote:
>> Besides I=20
>> can already imagine PMS-related discussion regarding "make the PMs che=
ck=20
for rdeps per default before unmerging things" - thx but no thx.
> This is not related to PMS. Paludis for example does it already with th=
e
> current EAPIs.
So how does Paludis handle those issues?
(Read my comments about "emerge" atomicy below)
> It is a problem which can _only_ be solved at the PM level. You have to
> tell the PM when API breakages happen. Either by slotting the lib or by
> something else.
^^^^^^^^^^^^^^^
This is important - as slotting is not a practical solution. What is it t=
hen?
> Using guesswork to determine whether or not a library
> should be removed may be a temporary solution. Remember: you're
> partially ignoring a users request since he wanted the package to be
> removed - and we all know how things like "protect the user from
> himself" end up.
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.<sth> 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
--=20
regards
MM