From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9B8E513877A for ; Sun, 27 Jul 2014 15:44:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9C68E0D99; Sun, 27 Jul 2014 15:44:20 +0000 (UTC) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C4933E0D8C for ; Sun, 27 Jul 2014 15:44:19 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id k15so6447359qaq.38 for ; Sun, 27 Jul 2014 08:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=d2bBcQPlZAhp+LuUTGcTwXMoZzziJNA7M02UC6IIOr8=; b=QT//XbiPEC89E1boZWCbpwdlPY+8/4G50j+PNDmmLi41enpkwNQnTOYF4vIYL11Tz/ vJNAT4cxk1dGcAyzC7hBoENqGjYFNDufmeJU/T9+PYl4vVg7L1Bj+UJfMWMeRWJ3Yg7+ JbR/25rgG1aIZVmg+hcGnoofTINXU3EDTjhb8vAeYPIowxbjLKD27aVHyQQBZU1lIysL fjR19NKv7vRW+tih8noLdTLxLCweDLnkN6HFYD2zTlQzeedn/o5flw5kRVMHDFPmXZiX d9H3kK/mwepX8HLTm7ZfH8xDZ/qcjhHCNYp8HAg6IhTio+8MjjAIWekK9mq6gl4Wvnqh bS2g== 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 X-Received: by 10.224.131.8 with SMTP id v8mr50214012qas.31.1406475858959; Sun, 27 Jul 2014 08:44:18 -0700 (PDT) Received: by 10.140.44.34 with HTTP; Sun, 27 Jul 2014 08:44:18 -0700 (PDT) In-Reply-To: References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53D5072E.3030305@gentoo.org> Date: Mon, 28 Jul 2014 03:44:18 +1200 Message-ID: Subject: Re: [gentoo-dev] don't rely on dynamic deps From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=047d7b624e72f5643704ff2eada9 X-Archives-Salt: 6fdc12fe-5578-4cff-bb9b-7cfea50ff760 X-Archives-Hash: 6fdee8cd10fd9dcad4efefeff8233dc5 --047d7b624e72f5643704ff2eada9 Content-Type: text/plain; charset=UTF-8 On 28 July 2014 02:42, Rich Freeman wrote: > One thing I would question in that table is "applied immediately (but > can break hard when dynamic-deps stop working))." How can dynamically > removing an "unused dependency" cause something to break, setting > aside bugs in the package manager? If removing a dependency causes > something to break, how can it be "unused?" > My apologies if this scenario has been explained before, I saw things along these lines, but must may have missed their point: I get the impression that this happens: 1. User installs Foo 2. Gentoo needs to change what Foo depends on 3. Gentoo simply tweaks the ebuild and doesn't bump [A] 4. User syncs. 5. Subsequent emerges see dependencies from [A] which are fixed and works in the interim 6. A gets removed. 7. User syncs. 8. Shadowing effect of [A] is removed, and Foo is now back depending on the wrong thing. =~ So although this problem will be resolved by also removing Foo, Foo still exists on the system with bad dependencies which could lead to some kind of problem, preventing emerge resolution from making sense. Sure, Foo will get reaped by a depclean if it is no longer in world and nothing depends on it, .... but depclean tends to require world to be deeply resolved first. And more questions for the -r1.1 style "Ship a new ebuild" style proposal. ::gentoo ships Foo-1.0 ::whatever *also* ships Foo-1.0 ( with different dependencies ) User installs from ::gentoo ::Whatever publishes a -r0.1 style ( or equivalent) dependency fix What happens for the user, and why. I'm of the mind ::Whatever should not tamper with ::gentoo here, though it could be useful, it could also prove problematic. Or maybe the idea is just too weird and quirky to implement this way. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL --047d7b624e72f5643704ff2eada9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 28 July 2014 02:42, Rich Freeman <rich0@gentoo.org> wrote:=
One thing I would = question in that table is "applied immediately (but
can break hard when dynamic-deps stop working))." =C2=A0How can dynami= cally
removing an "unused dependency" cause something to break, setting=
aside bugs in the package manager? =C2=A0If removing a dependency causes something to break, how can it be "unused?"

My apologies if this scenar= io has been explained before, I saw things along these lines, but must may = have missed their point:

I get the impression that this happens= :

1. User installs Foo
2. Gentoo needs to change what Foo depends on
3. Gentoo simply tweaks the ebuild and doesn'= ;t bump [A]
4. User syncs.
5. Subsequent emerges see dependencies from [A] whi= ch are fixed and works in the interim
6. A gets removed.
7. User syncs.
8. Shadowi= ng effect of [A] is removed, and Foo is now back depending on the wrong thi= ng.

=3D~ So although this problem will be = resolved by also removing Foo, Foo still exists on the system with bad depe= ndencies which could lead to some kind of problem, preventing emerge resolu= tion from making sense.

Sure, Foo will get reaped by a depclea= n if it is no longer in world and nothing depends on it, .... but depclean = tends to require world to be deeply resolved first.



And more questions for the -r1.1 style "Shi= p a new ebuild" style proposal.

::gentoo ships Foo-1.0
::whatever *al= so* ships Foo-1.0 ( with different dependencies )

User installs from ::gentoo

::Whatever publishes a -r0.1 style ( or equiv= alent) dependency fix

What happens= for the user, and why.

I'm of the mind ::Whatever should = not tamper with ::gentoo here, though it could be useful, it could also pro= ve problematic.

Or maybe the idea = is just too weird and quirky to implement this way.

--
--047d7b624e72f5643704ff2eada9--