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 |
> |
20 |
|
21 |
Rich, this is a _fundamental_ problem we have in gentoo. It's the lack |
22 |
of a development model. |
23 |
|
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 |
> |
36 |
|
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. |
40 |
|
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. |
46 |
|
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. |
54 |
|
55 |
|
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 |
> |
69 |
|
70 |
Gentoo is becoming anti-modular. That is contradictory to our |
71 |
meta-distribution model. |
72 |
|
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. |