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 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 ; Mon, 5 Apr 2010 06:17:16 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so919555fga.10 for ; 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 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: 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" 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. 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