Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12

[hasufell <hasufell@gentoo.org>]

Rich Freeman:
> On Fri, Aug 1, 2014 at 9:37 AM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Fri, 1 Aug 2014 09:24:46 -0400
>> Rich Freeman <rich0@gentoo.org> 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.
> 

Rich, this is a _fundamental_ problem we have in gentoo. It's the lack
of a development model.

>>
>> * 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).
> 

We only have the current implementation. So what you are saying is again
just an idea without code. Voting on it now without a reference
implementation will not result in anything useful.

And that "update VDB" approach is not trivial and has to be thought
through a lot (problems were already pointed out by mgorny), maybe even
by fixing PMS before the PM. Otherwise we have not gained anything and
still randomly break 3rd party PMs by relying on portage specific
behavior. We are practically nullifying the effort PMS was started for.

It almost sounds to me like people want to keep the old development
model "let's fix this real quick".
I think what the portage team does is the only sane approach: fix the
dependency resolution regression (that's the _most_ important part of
the PM). And then... think about how to minimize rebuilds (mgorny is
apparently already working on that). If that leads to another dynamic
deps solution (although I doubt it), so be it.


> 
>> * 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.
> 

Gentoo is becoming anti-modular. That is contradictory to our
meta-distribution model.

Not only, but also because of that we will lose a lot of people to NixOS
in the next few years, I am pretty sure of that.