Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
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 14:00:37
In Reply to: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 by Ciaran McCreesh
1 On Fri, Aug 1, 2014 at 9:37 AM, Ciaran McCreesh
2 <ciaran.mccreesh@××××××××××.com> wrote:
3 > On Fri, 1 Aug 2014 09:24:46 -0400
4 > Rich Freeman <rich0@g.o> wrote:
5 >> The thing is, with @preserved-rebuild I don't have to run
6 >> revdep-rebuild for the packages that either can't be or simply aren't
7 >> migrated to slot operator deps. That is a huge win. Also, random
8 >> things aren't broken during the time that I'm rebuilding, so I don't
9 >> end up chrooting into my system from a rescue CD when I forget to run
10 >> revdep-rebuild. I'll be happy when the day comes when we can get rid
11 >> of it, but that day is not yet here.
12 >
13 > Unfortunately, like dynamic dependencies, there's a vicious feedback
14 > cycle of increasingly ugly hacks with preserved-rebuild.
16 No argument there at all. Hence my statement that I'll be happy when
17 the day comes when I can be rid of it.
19 >
20 >> Generally speaking portage has favored usability over beauty of
21 >> design. That has made it harder to maintain, but far more popular.
22 >
23 > Portage favours usability in the case that nothing goes wrong, and it
24 > does it by making it ever more likely that something will go horribly
25 > wrong to the point that you have to give up and reinstall everything.
27 So, I've never had to reinstall everything, and this is on a system
28 that has basically been continuously updated since around 2002-3 that
29 has used multiple package managers, desktop environments, etc.
31 In my experience things go wrong with portage only VERY rarely. I
32 agree that it is undesirable when they do.
34 > Paludis tries hard to make sure everything is correct, at the expense
35 > that you have to invest smaller amounts of time as you go along fixing
36 > errors. The key point is, this investment would be much smaller if the
37 > quality of inputs was higher. This would be good for users, but also
38 > for developers: wouldn't you like to replace all your horrible
39 > complicated eclasses that generate perverse dependency strings with
40 > something much simpler?
42 I absolutely would love to see this.
44 The thing is, giving up things like @preserved-rebuild seems a bit
45 like threatening to kill kittens until people wake up and clean their
46 code. We're talking about ripping out 80% solutions in favor of 20%
47 solutions in order to motivate ourselves to build 100% solutions.
48 Burning bridges has the advantage of ideological purity, but it isn't
49 always the most practical option.
51 >
52 >> And what I'm really asking for here is for somebody to actually
53 >> explain what is actually wrong with dynamic dependencies.
54 >
55 > The big issues are:
57 Thanks.
59 >
60 > * They suddenly stop working if an ebuild is removed.
61 >
63 This is only the result of the current implementation, which begins
64 taking into account dynamic dependencies but then doesn't update VDB.
65 I think a better approach is that once a dynamic dependency is used,
66 the VDB should be updated to reflect it. Then there is no breakage
67 when ebuilds are removed. For PMs that don't implement dynamic deps
68 this just reduces to current behavior (they never use a dynamic dep,
69 so they don't update VDB).
71 > * They can make a 'sync' break a user's system.
73 I think we need to be careful with terms like "break" here. A sync
74 can result in a package suddenly having missing dependencies.
76 The thing is, there is a good chance they were missing them before the
77 sync, and the package manager was just blissfully unaware of this
78 because the dependency string was wrong.
80 That is my concern with this kind of approach. It results in a much
81 cleaner data model, but it doesn't actually fix the reality that
82 things break when they have wrong dependencies. With dynamic
83 dependencies the solution is that the PM just resolves the new
84 dependency. When static deps the solution is to revbump the package
85 forcing a complete rebuild just to get the new dependency to resolve.
86 Either way the package is broken until the dep is added (perhaps in a
87 subtle way).
89 >
90 > * They don't work with binary packages.
91 >
93 Sort-of. This is really just the VDB updating problem again, though
94 complicated by the fact that your binary package contains its own VDB.
95 It might be fixable at time of merging it, and if the original ebuild
96 isn't around at that time then you're back to the static dep model
97 which either breaks or not in the same way it would have before.
99 > * They don't work with overlays.
100 >
101 > * They don't work with "resurrecting" packages in overlays.
103 A lot of things don't work with overlays when it comes to changing
104 dependencies. The only reason we can do a lot of things in portage is
105 that we modify reverse deps along with the deps themselves.
107 I haven't thought overlays through, and I'm willing to believe that
108 things break in odd ways with overlays. We may never be able to
109 handle dynamic deps properly with them.
111 >
112 > * They're utterly incompatible with subslot deps.
114 I get that they aren't implemented with subslot deps. I'm not quite
115 sure why they can't be. When a new dep shows up, record the subslot
116 used to satisfy it when it is first satisifed.
118 >
119 > * Someone adds selinux support to foo. Then a new bar starts requiring
120 > foo[selinux]. The user hasn't rebuilt their foo to get selinux
121 > support, but the dependency is still met, thanks to dynamic
122 > dependencies.
123 >
125 I don't see this as having anything to do with dynamic dependencies.
126 If foo was built without selinux, then it wouldn't meet the
127 dependency. USE changes can't be assumed as not impacting the
128 installed files - I doubt this would be true in even a small minority
129 of cases.
131 > * The ruby-config example (details from memory, probably inaccurate,
132 > but the idea is right): Ruby ebuilds used to dep upon something like
133 > ruby-config, and they used it in pkg_prerm. The ebuilds were changed
134 > to use eselect-ruby instead. Users would replace ruby-config with
135 > eselect-ruby, and then be unable to uninstall or upgrade old ebuilds,
136 > because "dynamic" dependencies incorrectly changed the dependency
137 > without changing the pkg_prerm function.
139 Thanks. This is helpful.
141 I'm not entirely sure if this is just an implementation issue.
143 >
144 > But most fundamentally, the idea that a thing in VDB is somehow always
145 > associated with exactly one ebuild in the tree, and that changes to
146 > that ebuild are reflected in VDB, just doesn't work except in trivial
147 > cases.
149 I'll ponder this a bit.
151 The specifics are helpful. Even if many of these debatably have
152 solutions I do agree that we aren't there today.
154 Rich


Subject Author
Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 hasufell <hasufell@g.o>
Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>