Re: [gentoo-project] Some focus for Gentoo

[hasufell]

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

All copies are known to the PM. That's nothing like bundles libs or
static linkage. It's probably a triviality to develop a tool that checks
for vulnerable libraries (not sure if there already is one).

I didn't say we should become NixOS. It was just one example how
decentralized packaging CAN work. There are other examples.

>
>>> 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?
>

It is better, because you can actually choose what you want without
messing with complex masks and workarounds.
And because people could even set up monolithic repositories (actual
distros) that merge the work of several overlays (that's what happens in
NixOS afaiu, some companies seem to be interested in that work too),
straightening out things, checking for compatibility, removing
overlapping parts, etc.
People already use overlays so extensively that I don't think the world
would collapse from the user perspective. And keep in mind that a lot of
gentoo projects already moved their main work to github, because they
cannot keep up the massive amount of work without community contributors.

I think modularity does not only make sense for programming in general,
but also for packaging. But there must be a concept behind it as well,
otherwise you just get terrible fragmentation and ::mynick overlays (see
exherbo).

The main point about decentralized packaging is to shrink the tree (and
needed manpower) and allow more community effort to shape the "distro"
while still maintaining QA through a review workflow (to not become the
next arch linux user repository, aka AUR).
Then you can focus on what is most important: PM, EAPI, toolchain maybe
and most importantly... review.

But I've said most of this already.

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

I don't have a completely worked out idea for gentoo. I couldn't even
write a GLEP about this and I certainly won't, because it would be a
huge waste of time. The level of enthusiasm is just too low and any such
thing cannot and will not happen on GLEP level. It would have to be a
process, a community effort, not something the council decides on and
says "ok, now we can implement it" and would imply studying other
distros, checking out their workflow etc.

And btw., this was only one of two proposals.

My point was: it's not enough talking about "what should we focus on?".
How do you implement that focus?

What's your idea there, except of keeping status quo which clearly does
not work since even gentoo oldtimers seem to realize something is going
wrong?