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

[Rich Freeman <rich0@gentoo.org>]

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.

>
>> Generally speaking portage has favored usability over beauty of
>> design.  That has made it harder to maintain, but far more popular.
>
> Portage favours usability in the case that nothing goes wrong, and it
> does it by making it ever more likely that something will go horribly
> wrong to the point that you have to give up and reinstall everything.

So, I've never had to reinstall everything, and this is on a system
that has basically been continuously updated since around 2002-3 that
has used multiple package managers, desktop environments, etc.

In my experience things go wrong with portage only VERY rarely.  I
agree that it is undesirable when they do.

> Paludis tries hard to make sure everything is correct, at the expense
> that you have to invest smaller amounts of time as you go along fixing
> errors. The key point is, this investment would be much smaller if the
> quality of inputs was higher. This would be good for users, but also
> for developers: wouldn't you like to replace all your horrible
> complicated eclasses that generate perverse dependency strings with
> something much simpler?

I absolutely would love to see this.

The thing is, giving up things like @preserved-rebuild seems a bit
like threatening to kill kittens until people wake up and clean their
code.  We're talking about ripping out 80% solutions in favor of 20%
solutions in order to motivate ourselves to build 100% solutions.
Burning bridges has the advantage of ideological purity, but it isn't
always the most practical option.

>
>> And what I'm really asking for here is for somebody to actually
>> explain what is actually wrong with dynamic dependencies.
>
> The big issues are:

Thanks.

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

> * They can make a 'sync' break a user's system.

I think we need to be careful with terms like "break" here.  A sync
can result in a package suddenly having missing dependencies.

The thing is, there is a good chance they were missing them before the
sync, and the package manager was just blissfully unaware of this
because the dependency string was wrong.

That is my concern with this kind of approach.  It results in a much
cleaner data model, but it doesn't actually fix the reality that
things break when they have wrong dependencies.  With dynamic
dependencies the solution is that the PM just resolves the new
dependency.  When static deps the solution is to revbump the package
forcing a complete rebuild just to get the new dependency to resolve.
Either way the package is broken until the dep is added (perhaps in a
subtle way).

>
> * They don't work with binary packages.
>

Sort-of.  This is really just the VDB updating problem again, though
complicated by the fact that your binary package contains its own VDB.
It might be fixable at time of merging it, and if the original ebuild
isn't around at that time then you're back to the static dep model
which either breaks or not in the same way it would have before.

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

>
> * They're utterly incompatible with subslot deps.

I get that they aren't implemented with subslot deps.  I'm not quite
sure why they can't be.  When a new dep shows up, record the subslot
used to satisfy it when it is first satisifed.

>
> * Someone adds selinux support to foo. Then a new bar starts requiring
>   foo[selinux]. The user hasn't rebuilt their foo to get selinux
>   support, but the dependency is still met, thanks to dynamic
>   dependencies.
>

I don't see this as having anything to do with dynamic dependencies.
If foo was built without selinux, then it wouldn't meet the
dependency.  USE changes can't be assumed as not impacting the
installed files - I doubt this would be true in even a small minority
of cases.

> * The ruby-config example (details from memory, probably inaccurate,
>   but the idea is right): Ruby ebuilds used to dep upon something like
>   ruby-config, and they used it in pkg_prerm. The ebuilds were changed
>   to use eselect-ruby instead. Users would replace ruby-config with
>   eselect-ruby, and then be unable to uninstall or upgrade old ebuilds,
>   because "dynamic" dependencies incorrectly changed the dependency
>   without changing the pkg_prerm function.

Thanks.  This is helpful.

I'm not entirely sure if this is just an implementation issue.

>
> But most fundamentally, the idea that a thing in VDB is somehow always
> associated with exactly one ebuild in the tree, and that changes to
> that ebuild are reflected in VDB, just doesn't work except in trivial
> cases.

I'll ponder this a bit.

The specifics are helpful.  Even if many of these debatably have
solutions I do agree that we aren't there today.

Rich