Gentoo Archives: gentoo-project

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12
Date: Fri, 01 Aug 2014 13:37:52
In Reply to: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 by Rich Freeman
1 On Fri, 1 Aug 2014 09:24:46 -0400
2 Rich Freeman <rich0@g.o> wrote:
3 > The thing is, with @preserved-rebuild I don't have to run
4 > revdep-rebuild for the packages that either can't be or simply aren't
5 > migrated to slot operator deps. That is a huge win. Also, random
6 > things aren't broken during the time that I'm rebuilding, so I don't
7 > end up chrooting into my system from a rescue CD when I forget to run
8 > revdep-rebuild. I'll be happy when the day comes when we can get rid
9 > of it, but that day is not yet here.
11 Unfortunately, like dynamic dependencies, there's a vicious feedback
12 cycle of increasingly ugly hacks with preserved-rebuild. People start
13 to use it, and it sometimes doesn't work, so another hack is added in
14 to work around one thing at the expense of three others, so people
15 carry on using it, so another hack is added in, and so on. It's not a
16 sustainable development model, and it's not something that will be
17 fixed by letting users and developers continue with a short-term view.
19 > Generally speaking portage has favored usability over beauty of
20 > design. That has made it harder to maintain, but far more popular.
22 Portage favours usability in the case that nothing goes wrong, and it
23 does it by making it ever more likely that something will go horribly
24 wrong to the point that you have to give up and reinstall everything.
25 Paludis tries hard to make sure everything is correct, at the expense
26 that you have to invest smaller amounts of time as you go along fixing
27 errors. The key point is, this investment would be much smaller if the
28 quality of inputs was higher. This would be good for users, but also
29 for developers: wouldn't you like to replace all your horrible
30 complicated eclasses that generate perverse dependency strings with
31 something much simpler?
33 > And what I'm really asking for here is for somebody to actually
34 > explain what is actually wrong with dynamic dependencies.
36 The big issues are:
38 * They suddenly stop working if an ebuild is removed.
40 * They can make a 'sync' break a user's system.
42 * They don't work with binary packages.
44 * They don't work with overlays.
46 * They don't work with "resurrecting" packages in overlays.
48 * They're utterly incompatible with subslot deps.
50 * Someone adds selinux support to foo. Then a new bar starts requiring
51 foo[selinux]. The user hasn't rebuilt their foo to get selinux
52 support, but the dependency is still met, thanks to dynamic
53 dependencies.
55 * The ruby-config example (details from memory, probably inaccurate,
56 but the idea is right): Ruby ebuilds used to dep upon something like
57 ruby-config, and they used it in pkg_prerm. The ebuilds were changed
58 to use eselect-ruby instead. Users would replace ruby-config with
59 eselect-ruby, and then be unable to uninstall or upgrade old ebuilds,
60 because "dynamic" dependencies incorrectly changed the dependency
61 without changing the pkg_prerm function.
63 But most fundamentally, the idea that a thing in VDB is somehow always
64 associated with exactly one ebuild in the tree, and that changes to
65 that ebuild are reflected in VDB, just doesn't work except in trivial
66 cases.
68 --
69 Ciaran McCreesh


File name MIME type
signature.asc application/pgp-signature