Re: [gentoo-project] Some focus for Gentoo

[Rich Freeman]

On Wed, Jan 21, 2015 at 11:36 AM, Julian <hasufell@××××××××.de> wrote:
>
> We would need much better tools and PM support for overlays. I've talked
> about this too and there are examples of at least two distros that are
> running a more decentralized model:
> 1. NixOS, also see my thread on nix-dev about how they want to ensure
> focus [0]

I still don't get how NixOS avoids some fundamental issues.  As I
understand it they assign a unique ID to every build of everything,
and the dependencies are expressed in the same way.  So, my build 123
of appfoo v1.1 depends on build 456 of libz v2.  Your package might
depend on build 457 of libz v2, and that is fine since both versions
will be installed side-by-side.  Then we get to have two copies of
libz in RAM and maybe build 456 has a security vulnerability.  It is
better than static linking, but not by far.

Sure, we could do that with Gentoo, but I'm not sure this really
addresses the concerns you brought up, like...


>> How
>> can we have both games.eclass and no games.eclass but due to a
>> technical/methodology change there are now less problems?  Ditto for
>> the two multilib implementations?
>>
>
> Well, for once: forking an overlay is easier than forking the whole
> gentoo tree.
> But that's not necessarily the main point. Ideas would not be decided by
> "who does something first in the tree", but by more dynamic processes
> about approval in the community. Someone starts a repo and does stuff.
> If people like it, they are going to use it and focus their contribution
> there.

So, which is it?  You point out that we have inconsistencies in our
tree because we have games.eclass but we don't force everybody to use
it.

How is it better if the games are scattered across 47 overlays
instead, and some of them use games.eclass, others use something else
that sticks games in an entirely different group/path/whatever, others
follow upstream, and maybe half the overlays do security updates and
the other half don't?  Maybe half of them use the multilib eclass and
half use portage-multilib.

So, are we OK with inconsistencies or not?  If we are OK with them,
then why complain about it?

>
>> I think that a major shakeup only makes sense if we can actually
>> demonstrate a new model in operation, and it actually solves our
>> problems.
>>
>
> I've already given two examples of a new model in operation. Also, I
> haven't said "let's do this tomorrow". IMO it will never happen anyway.
> I am convinced that gentoo will rather die slowly, because people are
> afraid to change the course which leads us to a nice thick wall, because
> we might derail.
> I'm still not sure if it will die because of "lack of manpower" or
> because our technology is so messed up that it becomes unusable.

So, I'm not convinced that we won't find our way, but if Gentoo stops
existing because we've all found a better way and moved on to it, then
really there is no loss unless you're really attached to the name,
"Gentoo."  None of us own stock in the Gentoo Foundation.  If
something new already exists and is doing it better, and we all just
decide to switch, then we all reap the benefits.

However, it seems likely to me that if there were an overwhelming
sense that a new model would really work for most of us, we'd change.
The problem is that not everybody is here for the same reason, and
we're best off trying to tap into that rather than fighting it.

-- 
Rich