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 > 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. 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. > 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. > Though I'd recommend you put the user and group allocation in the ebuild. > Then your "list" is trivially generable by parsing portage. Further, you > can *enforce* these allocations when calculating the dependency tree. If > you're not enforcing them, what's the point? Is there a benefit without > said enforcement? As stated, enewuser/enewgroup would utilize such a list/database directly. In addition to repoman so issues are prevented before ebuilds are committed. > > 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. > 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. > But trying to set up a list for everyone to move in lockstep with seems to > me like a bad way to go. See my other post, other distros already do this for core system accounts. > 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. > 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 > 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. -- William L. Thomson Jr.
signature.asc
Description: This is a digitally signed message part.
