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 685641391DB for ; Fri, 1 Aug 2014 14:00:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EEFBAE099D; Fri, 1 Aug 2014 14:00:35 +0000 (UTC) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 52BC8E08B5 for ; Fri, 1 Aug 2014 14:00:35 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ik5so6697624vcb.34 for ; Fri, 01 Aug 2014 07:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Po3jizyTFiOnuaSfnYq2lg9Fh6bOuBkUz84uVk6fbYw=; b=kiBOo5BbkGBEy9ZrEzoulMUZFZWWw5okjMtHBm9zz+Aa643d7hAbiUsHdfFn7PHfQe Um/QCwavIG0zhVzaFDjd3c+uz2fUytcGsVsHp4OMwIL/vVpkBBiStkJJMYPuZySN0oCd oo4Qc2FE9IcOnDyjbxRkC0Ulvo9aAlgNZMAi86XkRKTKHh7lop7rdaqjSvbLMiF42+mG 1xhhnlKVNLesYTXrymD4zKP/DvLM+dN3b6T3bjOsX11+VPrdqHkU0gsKA3+XlCjSJk90 Uqm+m2k54GXrv/Mf3qo755/iDHmwowt6h91tWKYx5qj/Ys0UaEl6/r69WVH+VfBs7eTn GTkA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.36.131 with SMTP id q3mr1689641vdj.90.1406901634470; Fri, 01 Aug 2014 07:00:34 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Fri, 1 Aug 2014 07:00:34 -0700 (PDT) In-Reply-To: <20140801143741.1ebf8df6@googlemail.com> References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> <53DA69DA.8020000@gentoo.org> <53DB7F42.4010609@gentoo.org> <53DB901C.4090004@gentoo.org> <20140801143741.1ebf8df6@googlemail.com> Date: Fri, 1 Aug 2014 10:00:34 -0400 X-Google-Sender-Auth: gdB0DNj1ImzGodOIBs8OqFOqclc Message-ID: Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 2472e255-576e-43e2-9bae-a83e0f15193e X-Archives-Hash: bd274921e9e7fc9ca60eca289b820bd5 On Fri, Aug 1, 2014 at 9:37 AM, Ciaran McCreesh wrote: > On Fri, 1 Aug 2014 09:24:46 -0400 > Rich Freeman wrote: >> The thing is, with @preserved-rebuild I don't have to run >> revdep-rebuild for the packages that either can't be or simply aren't >> migrated to slot operator deps. That is a huge win. Also, random >> things aren't broken during the time that I'm rebuilding, so I don't >> end up chrooting into my system from a rescue CD when I forget to run >> revdep-rebuild. I'll be happy when the day comes when we can get rid >> of it, but that day is not yet here. > > Unfortunately, like dynamic dependencies, there's a vicious feedback > cycle of increasingly ugly hacks with preserved-rebuild. No argument there at all. Hence my statement that I'll be happy when the day comes when I can be rid of it. > >> Generally speaking portage has favored usability over beauty of >> design. That has made it harder to maintain, but far more popular. > > Portage favours usability in the case that nothing goes wrong, and it > does it by making it ever more likely that something will go horribly > wrong to the point that you have to give up and reinstall everything. So, I've never had to reinstall everything, and this is on a system that has basically been continuously updated since around 2002-3 that has used multiple package managers, desktop environments, etc. In my experience things go wrong with portage only VERY rarely. I agree that it is undesirable when they do. > Paludis tries hard to make sure everything is correct, at the expense > that you have to invest smaller amounts of time as you go along fixing > errors. The key point is, this investment would be much smaller if the > quality of inputs was higher. This would be good for users, but also > for developers: wouldn't you like to replace all your horrible > complicated eclasses that generate perverse dependency strings with > something much simpler? I absolutely would love to see this. The thing is, giving up things like @preserved-rebuild seems a bit like threatening to kill kittens until people wake up and clean their code. We're talking about ripping out 80% solutions in favor of 20% solutions in order to motivate ourselves to build 100% solutions. Burning bridges has the advantage of ideological purity, but it isn't always the most practical option. > >> And what I'm really asking for here is for somebody to actually >> explain what is actually wrong with dynamic dependencies. > > The big issues are: Thanks. > > * They suddenly stop working if an ebuild is removed. > This is only the result of the current implementation, which begins taking into account dynamic dependencies but then doesn't update VDB. I think a better approach is that once a dynamic dependency is used, the VDB should be updated to reflect it. Then there is no breakage when ebuilds are removed. For PMs that don't implement dynamic deps this just reduces to current behavior (they never use a dynamic dep, so they don't update VDB). > * They can make a 'sync' break a user's system. I think we need to be careful with terms like "break" here. A sync can result in a package suddenly having missing dependencies. The thing is, there is a good chance they were missing them before the sync, and the package manager was just blissfully unaware of this because the dependency string was wrong. That is my concern with this kind of approach. It results in a much cleaner data model, but it doesn't actually fix the reality that things break when they have wrong dependencies. With dynamic dependencies the solution is that the PM just resolves the new dependency. When static deps the solution is to revbump the package forcing a complete rebuild just to get the new dependency to resolve. Either way the package is broken until the dep is added (perhaps in a subtle way). > > * They don't work with binary packages. > Sort-of. This is really just the VDB updating problem again, though complicated by the fact that your binary package contains its own VDB. It might be fixable at time of merging it, and if the original ebuild isn't around at that time then you're back to the static dep model which either breaks or not in the same way it would have before. > * They don't work with overlays. > > * They don't work with "resurrecting" packages in overlays. A lot of things don't work with overlays when it comes to changing dependencies. The only reason we can do a lot of things in portage is that we modify reverse deps along with the deps themselves. I haven't thought overlays through, and I'm willing to believe that things break in odd ways with overlays. We may never be able to handle dynamic deps properly with them. > > * They're utterly incompatible with subslot deps. I get that they aren't implemented with subslot deps. I'm not quite sure why they can't be. When a new dep shows up, record the subslot used to satisfy it when it is first satisifed. > > * Someone adds selinux support to foo. Then a new bar starts requiring > foo[selinux]. The user hasn't rebuilt their foo to get selinux > support, but the dependency is still met, thanks to dynamic > dependencies. > I don't see this as having anything to do with dynamic dependencies. If foo was built without selinux, then it wouldn't meet the dependency. USE changes can't be assumed as not impacting the installed files - I doubt this would be true in even a small minority of cases. > * The ruby-config example (details from memory, probably inaccurate, > but the idea is right): Ruby ebuilds used to dep upon something like > ruby-config, and they used it in pkg_prerm. The ebuilds were changed > to use eselect-ruby instead. Users would replace ruby-config with > eselect-ruby, and then be unable to uninstall or upgrade old ebuilds, > because "dynamic" dependencies incorrectly changed the dependency > without changing the pkg_prerm function. Thanks. This is helpful. I'm not entirely sure if this is just an implementation issue. > > But most fundamentally, the idea that a thing in VDB is somehow always > associated with exactly one ebuild in the tree, and that changes to > that ebuild are reflected in VDB, just doesn't work except in trivial > cases. I'll ponder this a bit. The specifics are helpful. Even if many of these debatably have solutions I do agree that we aren't there today. Rich