Gentoo Archives: gentoo-project

From: hasufell <hasufell@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:36:21
In Reply to: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 by Rich Freeman
1 Rich Freeman:
2 > On Fri, Aug 1, 2014 at 9:37 AM, Ciaran McCreesh
3 > <ciaran.mccreesh@××××××××××.com> wrote:
4 >> On Fri, 1 Aug 2014 09:24:46 -0400
5 >> Rich Freeman <rich0@g.o> wrote:
6 >>> The thing is, with @preserved-rebuild I don't have to run
7 >>> revdep-rebuild for the packages that either can't be or simply aren't
8 >>> migrated to slot operator deps. That is a huge win. Also, random
9 >>> things aren't broken during the time that I'm rebuilding, so I don't
10 >>> end up chrooting into my system from a rescue CD when I forget to run
11 >>> revdep-rebuild. I'll be happy when the day comes when we can get rid
12 >>> of it, but that day is not yet here.
13 >>
14 >> Unfortunately, like dynamic dependencies, there's a vicious feedback
15 >> cycle of increasingly ugly hacks with preserved-rebuild.
16 >
17 > No argument there at all. Hence my statement that I'll be happy when
18 > the day comes when I can be rid of it.
19 >
21 Rich, this is a _fundamental_ problem we have in gentoo. It's the lack
22 of a development model.
24 >>
25 >> * They suddenly stop working if an ebuild is removed.
26 >>
27 >
28 > This is only the result of the current implementation, which begins
29 > taking into account dynamic dependencies but then doesn't update VDB.
30 > I think a better approach is that once a dynamic dependency is used,
31 > the VDB should be updated to reflect it. Then there is no breakage
32 > when ebuilds are removed. For PMs that don't implement dynamic deps
33 > this just reduces to current behavior (they never use a dynamic dep,
34 > so they don't update VDB).
35 >
37 We only have the current implementation. So what you are saying is again
38 just an idea without code. Voting on it now without a reference
39 implementation will not result in anything useful.
41 And that "update VDB" approach is not trivial and has to be thought
42 through a lot (problems were already pointed out by mgorny), maybe even
43 by fixing PMS before the PM. Otherwise we have not gained anything and
44 still randomly break 3rd party PMs by relying on portage specific
45 behavior. We are practically nullifying the effort PMS was started for.
47 It almost sounds to me like people want to keep the old development
48 model "let's fix this real quick".
49 I think what the portage team does is the only sane approach: fix the
50 dependency resolution regression (that's the _most_ important part of
51 the PM). And then... think about how to minimize rebuilds (mgorny is
52 apparently already working on that). If that leads to another dynamic
53 deps solution (although I doubt it), so be it.
56 >
57 >> * They don't work with overlays.
58 >>
59 >> * They don't work with "resurrecting" packages in overlays.
60 >
61 > A lot of things don't work with overlays when it comes to changing
62 > dependencies. The only reason we can do a lot of things in portage is
63 > that we modify reverse deps along with the deps themselves.
64 >
65 > I haven't thought overlays through, and I'm willing to believe that
66 > things break in odd ways with overlays. We may never be able to
67 > handle dynamic deps properly with them.
68 >
70 Gentoo is becoming anti-modular. That is contradictory to our
71 meta-distribution model.
73 Not only, but also because of that we will lose a lot of people to NixOS
74 in the next few years, I am pretty sure of that.