1 |
On Wednesday, November 30, 2016 1:22:07 PM EST Michael Mol wrote: |
2 |
> |
3 |
> |
4 |
> If Gentoo wants to do it internally, that's one thing. |
5 |
|
6 |
This list is about Gentoo internal things |
7 |
|
8 |
> But I would recommend |
9 |
> against inviting other distributions to use Gentoo's list, which was |
10 |
> something you seemed to be suggesting. Doing so asks that Gentoo shoulder |
11 |
> the bureaucratic load from other distributions that want things added to |
12 |
> Gentoo's list. |
13 |
|
14 |
Gentoo cannot force others to do anything. If Gentoo is leading in a |
15 |
direction, others choose to follow or not. Gentoo does not set standards that |
16 |
would be up to LSB and/or POSIX. |
17 |
|
18 |
My point is Gentoo should do its own thing, lead the way. Ideally others |
19 |
follow and it becomes a standard either in LSB or POSIX. Hopefully that will |
20 |
clarify my position. |
21 |
|
22 |
> If you want to tie this specifically to Gentoo packaging, that's fine. |
23 |
|
24 |
Which is why it is being discussed on a Gentoo development list and not |
25 |
others. |
26 |
|
27 |
> Though I'd recommend you put the user and group allocation in the ebuild. |
28 |
> Then your "list" is trivially generable by parsing portage. Further, you |
29 |
> can *enforce* these allocations when calculating the dependency tree. If |
30 |
> you're not enforcing them, what's the point? Is there a benefit without |
31 |
> said enforcement? |
32 |
|
33 |
As stated, enewuser/enewgroup would utilize such a list/database directly. In |
34 |
addition to repoman so issues are prevented before ebuilds are committed. |
35 |
|
36 |
> > This is not needless bureaucracy , this is necessary. |
37 |
> |
38 |
> Opinion. Why is it necessary? What is it necessary for? |
39 |
|
40 |
It is necessary so Gentoo base system installs are consistent from one system |
41 |
to the next, Just as RHEL and Debian, and likely others. When working with |
42 |
large amounts of installs, You want them all to be the same or as close to |
43 |
identical as possible. Thus the rise of Docker, CoreOS, etc. |
44 |
|
45 |
> Oh, I understand the problem, but you haven't explained why your solution is |
46 |
> the necessary solution to it, or how you would cope with the plethora of |
47 |
> edge cases I brought up. It would seem there are already many established |
48 |
> workarounds for the status quo, unstable-UID/GID in a cross-system context. |
49 |
|
50 |
My solution is to avoid such issues. I start with a common base image. I try |
51 |
to ensure anything else installed beyond that, which adds new users/groups is |
52 |
the same. At times I will re-image and use that as well for other similar |
53 |
systems. Rather than mess with doing the same install to many and trying to |
54 |
sync UID/GID. |
55 |
|
56 |
Think cloning rather than installing. |
57 |
|
58 |
> But trying to set up a list for everyone to move in lockstep with seems to |
59 |
> me like a bad way to go. |
60 |
|
61 |
See my other post, other distros already do this for core system accounts. |
62 |
|
63 |
> Less bad if you intend to keep it unique to |
64 |
> Gentoo, but the broader you make the scope, the more strain you'll put on |
65 |
> the ecosystem as a whole. |
66 |
|
67 |
Standards need to exist so there is consistency. In the absence of said |
68 |
standard, next best thing you can do is look to what others are doing and do |
69 |
the same. Thus I tend to say go with RedHat UID/GID over say Arch, maybe even |
70 |
Debian. But those two likely have larger install bases than most any other |
71 |
distro. If the UID/GID are the same between RedHat and Debian, that already |
72 |
makes a good deal of systems consistent now. |
73 |
|
74 |
> More daemons will be build that are intended to |
75 |
> run as local users. More software will be pushed into opaque blobs a la |
76 |
> Snap and Flatpack. |
77 |
|
78 |
I am talking about core system accounts |
79 |
|
80 |
> As a general rule, the bigger the hassle you make something, the less people |
81 |
> will want to engage. |
82 |
|
83 |
When standards exist, others will follow, ideally. When standards do not |
84 |
exist, everyone is left to their own way of doing things. IMHO it is less of a |
85 |
hassle to comply with standards than all the various ways of doing something. |
86 |
|
87 |
-- |
88 |
William L. Thomson Jr. |