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:03 AM, hasufell <hasufell@gentoo.org> wrote:
> Rich Freeman:
>>>
>>> Tree policy, I'm afraid, has to adapt to Portage; not the other way
>>> around.
>>
>> The reality is that both portage and the tree policy need to adapt to
>> the needs of the community, otherwise there won't be anybody around
>> maintaining either.
>
> Rich, we are almost at the point where portage is unmaintained. Can't
> say I feel sorry about that. I'd rather hack on paludis than portage
> (although it isn't exactly well documented and would probably take me 2+
> months just to understand some basics).

So, if you want an example of why I think most people prefer portage
to paludis, I'd bring up @preserved-rebuild.  It is the biggest hack
that anybody could have come up with, and I can easily list 47 ways of
why the way paludis does things is more
elegant/accurate/well-behaved/etc.

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.

Generally speaking portage has favored usability over beauty of
design.  That has made it harder to maintain, but far more popular.

And don't get me wrong - I ran paludis for years.  I didn't migrate
back to portage until it began to do more than just resolve
dependencies.

>
> Anyway, I don't think the recent reactions help in any way to boost
> portage development. People should really think about this and how this
> is perceived by the remaining portage devs. If you guys want to actually
> help portage, you should come up with code fixes that reduce the number
> of rebuilds instead of voting on unimplemented solutions (which I think
> is highly contradictory).
>

If we're just going to turn portage into paludis, why would we bother?
 I think that paludis largely exemplifies this kind of design already,
or it least it did so back when I was running it.

And what I'm really asking for here is for somebody to actually
explain what is actually wrong with dynamic dependencies.  I have seen
47 almost-certainly-sincere claims that they're broken, but little in
the way of examples, and the one that has been given (prerm) seems
likely to break with static deps the way it is implemented today (we
don't unmerge reverse-deps before upgrading the dep, which breaks
linking that might be required to unmerge the package in the first
place - though it probably only breaks 0.01% of the time and the cure
is likely worse than the disease).

The last thing I want to do here is frustrate somebody who is doing
the right thing.  I'd just like to understand their thinking, and I
think many others would like to understand as well.

Rich