Re: [gentoo-dev] RFC: Userkit.eclass

[Michael Mol]

On Wednesday, November 30, 2016 01:41:24 PM William L. Thomson Jr. wrote:
> On Wednesday, November 30, 2016 1:22:07 PM EST Michael Mol wrote:
> > If Gentoo wants to do it internally, that's one thing.
>
> This list is about Gentoo internal things

Here, let me bring up a bit of recent history from your Message-ID 
<assp.0140865882.25530652.rRlbQJgv4Y@wlt>, which had a signature of 
iEYEABECAAYFAlg8iAQACgkQTXGypIOqM1A2EgCglmZkNYaJ16qQkSxezTqCtI4/
PwoAnR2dW0XUFZk8QUmgrVwu+3OpRxS+
=tuat, which my client indicated matched the key 
0xC47A576A663995BADF1B54724D71B2A483AA3350, but I don't have your key trusted, 
so whatever:

> I believe the main reason such is the case is a lack of any such list or
> database for others to adhere to. Once again an area Gentoo could be
> leading.
> Had Gentoo done this years ago others might have adopted.

> IMHO it is something that should be  a part of LSB. If not POSIX in general.
> One cannot really change the past or current state of things. But can make
the future better.

> For now who cares about other OS or distros. If Gentoo gets its house in
> order
> others may follow.

I will note that it's this point when I first replied; that was the point when 
you chose to expand the scope outside Gentoo.

>
> > But I would recommend
> > against inviting other distributions to use Gentoo's list, which was
> > something you seemed to be suggesting. Doing so asks that Gentoo shoulder
> > the bureaucratic load from other distributions that want things added to
> > Gentoo's list.
>
> Gentoo cannot force others to do anything.

I didn't say force. I said invite.

> If Gentoo is leading in a
> direction, others choose to follow or not. Gentoo does not set standards
> that would be up to LSB and/or POSIX.
>
> My point is Gentoo should do its own thing, lead the way. Ideally others
> follow and it becomes a standard either in LSB or POSIX. Hopefully that will
> clarify my position.

As you noted, Arch appeared to attempt this, and others did not follow.

>
> > If you want to tie this specifically to Gentoo packaging, that's fine.
>
> Which is why it is being discussed on a Gentoo development list and not
> others.

That's fine. As I pointed out, I only started chiming in when you began 
advocating exporting Gentoo's list to a broader ecosystem.

[snip]

> > > This is not needless bureaucracy , this is necessary.
> >
> > Opinion. Why is it necessary? What is it necessary for?
>
> It is necessary so Gentoo base system installs are consistent from one
> system to the next, Just as RHEL and Debian, and likely others. When
> working with large amounts of installs, You want them all to be the same or
> as close to identical as possible. Thus the rise of Docker, CoreOS, etc.

If RHEL and Debian are consistent from one system to the next, obviously it's 
sensical to use their list. But why don't they use each others? Or am I 
missing something, and that's exactly what they're doing?

>
> > Oh, I understand the problem, but you haven't explained why your solution
> > is the necessary solution to it, or how you would cope with the plethora
> > of edge cases I brought up. It would seem there are already many
> > established workarounds for the status quo, unstable-UID/GID in a
> > cross-system context.
> My solution is to avoid such issues. I start with a common base image. I try
> to ensure anything else installed beyond that, which adds new users/groups
> is the same. At times I will re-image and use that as well for other
> similar systems. Rather than mess with doing the same install to many and
> trying to sync UID/GID.
>
> Think cloning rather than installing.

Sure. But if you clone a seed node, does it matter that a second from-scratch 
install may not have the same mapping?

[snip]

> > Less bad if you intend to keep it unique to
> > Gentoo, but the broader you make the scope, the more strain you'll put on
> > the ecosystem as a whole.
>
> Standards need to exist so there is consistency. In the absence of said
> standard, next best thing you can do is look to what others are doing and do
> the same. Thus I tend to say go with RedHat UID/GID over say Arch, maybe
> even Debian.   But those two likely have larger install bases than most any
> other distro. If the UID/GID are the same between RedHat and Debian, that
> already makes a good deal of systems consistent now.

If UID/GID are consistent between RH and Debian, then yeah, what you have is a 
de facto standard, and it would be reasonable to conform, if there are people 
who actually have a need for that cross-system mirroring.

>
> > More daemons will be build that are intended to
> > run as local users. More software will be pushed into opaque blobs a la
> > Snap and Flatpack.
>
> I am talking about core system accounts

Who decides what qualifies as a core system account?

If there's any trend I've been able to clearly observe over the last fifteen 
years, it's the grinding of such boundaries into finer and finer granularity. 
Heck, I think there was a thread on gentoo-user some time in the last few 
months where someone wanted to be able to use two different MTAs on the same 
host! (Obviously, he couldn't, but he had a use case.)

Heck, some time five or six years ago, I filed a bug report asking that some 
core package (maybe it was gcc?) have its build dependencies properly defined. 
I was told that wasn't going to happen, as doing that for all the core 
packages would be too difficult or some such; their dependencies would be left 
coarse. And now we've had threads in the last few months touching on resolving 
that very thing.

>
> > As a general rule, the bigger the hassle you make something, the less
> > people will want to engage.
>
> When standards exist, others will follow, ideally. When standards do not
> exist, everyone is left to their own way of doing things. IMHO it is less of
> a hassle to comply with standards than all the various ways of doing
> something.

For the packager, for sure. For developers trying to make new things, not so 
much.

-- 
:wq