| View previous topic :: View next topic |
| Author |
Message |
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
 Posted: Sat Aug 10, 2019 10:35 pm Post subject: |
 |
|
| sigh. |
|
| Back to top |
|
 |
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sat Aug 10, 2019 10:49 pm Post subject: |
|
|
| Anon-E-moose wrote: | | Code: | RDEPEND="${COMMON_DEPEND}
acct-group/input
acct-group/kvm
acct-group/render |
I see ... it all makes sense now, the above is so much easier than this
| Code: | enewgroup input 97
enewgroup kvm 78
enewgroup render 28 |
Wow, what genius *thumbs up* |
The downside of that is the GID is a magic number in the ebuild and there is the possibility of one ebuild incorrectly using a GID of a different group, or inconsistencies across machines. ( although QA of a commit could easily catch that... there is QA right???)
Since an eclass is acceptable for this, why can't there be a package with this info, controlled centrally, the the ebuild call would be echeckgroup kvm and the eclass (since eclass is acceptable) would check which GID to use and make if needed, likewise remove/disable if not used by any other upon emerge -C
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sat Aug 10, 2019 10:56 pm Post subject: |
|
|
What is your objection to it? the need or the implementation?
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sat Aug 10, 2019 10:57 pm Post subject: |
|
|
| Naib wrote: | | The downside of that is the GID is a magic number in the ebuild and there is the possibility of one ebuild incorrectly using a GID of a different group, |
It's always been that way.
| Quote: | | or inconsistencies across machines. |
Well there's certainly inconsistencies across various distros, when I've hand added group (for whatever reason they weren't there) I simply made sure the id was unique
| Quote: | | ( although QA of a commit could easily catch that... there is QA right???) |
No comment
| Quote: | | Since an eclass is acceptable for this, why can't there be a package with this info, controlled centrally, the the ebuild call would be echeckgroup kvm and the eclass (since eclass is acceptable) would check which GID to use and make if needed, likewise remove/disable if not used by any other upon emerge -C |
This could be done, along with several other workable solutions. A handful of devs made the decision though ... and here we are.
It does remind me that I need to clean out passwd and group to get rid of id's that I no longer need or use, old stuff from gnome-1 days, etc.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Sat Aug 10, 2019 11:14 pm Post subject: |
|
|
| asturm wrote: | | pjp wrote: | | asturm wrote: | | Yes, times x systems, times y packages. |
Thanks for clarifying. I disagree. |
You can pretend to disagree, but can you come up with a scheme to distribute a unique ID to n systems using existing facilities that is cheaper than forking an ebuild with less than 10 lines? |
*sigh*
Pretend?
Arbitrary limitations without sufficient description of requirements and more importantly a lack of definition for the problem and a desired outcome.
The strawman for you to tear apart... ebuilds could contain "REQUIRED_USERS=foo bar". A package (or two) containing the user and group to ID mapping. That solves the x systems, y packages problem. I'm counting 46 ebuilds in acct-group,user, so that overhead would be eliminated. Existing code could likely be resused, so whatever is currently adding the users and groups is already done. The advantage to this strawman is that it would theoretically also work on systems other than Gentoo.
But none of that addresses the manner in whiich the current chosen solution is being deployed without sufficient regard for its impact to users.
_________________
Quis separabit? Quo animo?
Last edited by pjp on Sat Aug 10, 2019 11:18 pm; edited 1 time in total |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Sat Aug 10, 2019 11:17 pm Post subject: |
|
|
| pjp wrote: | | A package (or two) containing the user and group to ID mapping. |
Overlays? Back to square one. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Sat Aug 10, 2019 11:20 pm Post subject: |
|
|
Local overrides as other items are locally overriden. /etc/portage?
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sat Aug 10, 2019 11:21 pm Post subject: |
|
|
right, so you have a sysml model covering the needs, the use-cases and the scenarios to show that this abomination pushed out meets the the stated needs and the use-cases and other options failed one or more such cases?
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sat Aug 10, 2019 11:25 pm Post subject: |
|
|
Okay, still not sure what you want since "the entire sentence" is vague, but I'll see what I can do:
- Alpine's maintained a list of GIDs for at least 8 years: Source
- Adélie -- being based on Alpine (until they rewrite abuild) -- handles its GIDs and UIDs in a similar manner, though they still haven't published it from what I could find: Source
- The RFCs with UIDs/GIDs, when they do mention another distro, are Arch or Red Hat, and it's right in the e-mail:
I found a wiki page listing the UIDs and GIDs that Gentoo is managing (through an e-mail instead of any official docs or, y'know, a news item), but no indication that the list is accessible through anything other than the wiki. An edit from August 8th by Mgorny added a link to the e-mail he posted regarding a more accessible form of the list, but bikeshed is still in progress. Said wiki page also lists Arch, Red Hat, and Fedora as DBs to check before posting to the list, which at least partially explains why people are only mentioning Arch and Red Hat. Debian at least has some sort of guidelines (Source), though I could not locate a single, canonical list. Given Debian's similar fetishism of bureaucracy, I suspect they have a list but it isn't easy to find.
The point here is only three other distros (all coalescing to the same userland, more or less) are listed for UID/GID databases, when it's a problem that all distros must solve; ergo one can infer that other distributions also have their own solution. However, in practice Gentoo devs are only considering Arch, Red Hat, and Fedora, and only accept an arbitrary number if it doesn't exist in the others. Logically, that means Gentoo's list will eventually match one list or another. The process for selecting IDs has inherent bias (and an implicit dependency) if you're checking an outside source and following it if found before making a decision. Personally, I expect a distro to check more than two distros before it claims to make a decision factoring in other distributions. Red Hat and Fedora are essentially the same, so the choice is really down to two. There are more than two distros in the world. There are more than two MAJOR distros, too.
So it brings me to my original question: What makes Arch or Red Hat authoritative or reliable sources for system architecture? What have they done that is worthy of trusting a meta distribution's architecture with? |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Sat Aug 10, 2019 11:28 pm Post subject: |
|
|
| pjp wrote: | | Local overrides as other items are locally overriden. /etc/portage? |
It's better than what we had prior to acct-*/*, but now you need to extend PMS, need a new EAPI, and need to setup a mechanism external to portage to distribute your custom IDs. All that to avoid a few dozen packages added to tree that work for all EAPIs and all PMs? There will have been other arguments on the list, but I didn't follow that discussion too closely. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Sat Aug 10, 2019 11:38 pm Post subject: |
|
|
I guess what it boils down to is easy access of information. What makes Adelie or Alpine authoritative distros, what are the numbers?
| spork_kitty wrote: | | The process for selecting IDs has inherent bias (and an implicit dependency) if you're checking an outside source and following it if found before making a decision. |
And are you concerned we are discriminating against uneven numbers? |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun Aug 11, 2019 2:18 am Post subject: |
|
|
| asturm wrote: | I guess what it boils down to is easy access of information. What makes Adelie or Alpine authoritative distros, what are the numbers?
| spork_kitty wrote: | | The process for selecting IDs has inherent bias (and an implicit dependency) if you're checking an outside source and following it if found before making a decision. |
And are you concerned we are discriminating against uneven numbers? |
Nothing's particularly authoritative about Alpine or Adélie. That's not the point, they were examples of distros that are managing their UIDs and GIDs centrally, like what Gentoo is trying to do. The point is if you're intending to look at other distributions to inform your choices, you ought to cast a wide net so you know where things really stand. I felt that much was obvious, so I apologize if that wasn't apparent. Limiting yourself to Arch and Red Hat only lets you see what they have used to solve the problem. It's simply a numbers game. Why isn't Debian listed? SuSE? Slackware? CRUX? Or even GoboLinux  Plainly, I expect Gentoo devs to have more perspective than what's en vogue. I like to think that we all use Gentoo because it gives us great flexibility to make Gentoo what we want it to be, not because it does things like everyone else. Choosing to consider only the most mainstream and controversial distros currently in the space is undeniably biased, and there is no supporting reasoning given for choosing Arch and Red Hat over others. By choosing to look at only a few distros, Gentoo is resigning itself to myopia. It cannot know that it made the right decision without having a broad and accurate perspective on an issue.
Worse yet, it still doesn't solve the real problem, which is handling broken UIDs/GIDs in the filesystem. It's not "if" it happens, but "when". Why add packages to the tree when you can extend Portage to be able to enforce file and directory permissions for packages? Does it not store the permissions of files it's managing in /var/db? (Hint: it doesn't; the CONTENTS file lists the object type, its path, a hash, and the timestamp) Couldn't it get a tool to check @world and apply/fix permissions? I get that someone has to write the code, but the solution being used right now isn't going to solve the problem long-term. It's a hack. It's adding bureaucratic overhead through the RFC-over-ML system (making migration and maintenance a hassle for devs, and their answer (api.gentoo.org) creates more technical work instead), adding churn to user systems (rebuilds), and expanding the size of the Portage DB by duplicating effort that was already being done in ebuilds. I cannot do anything new with acct-*/* packages that I couldn't do with their parent ebuilds before the split.
The behavior of acct-*/* packages is weird. They add users and groups, but don't remove them. So you can end up with X users and groups that aren't even in use on your system anymore. I understand the decision (to minimize leftover permissions being set to a no-longer-present user/group) but it means Portage doesn't clean up after itself after uninstalling a user. I can `emerge -c acct-user/foo` and "foo" will still be in /etc/passwd and /etc/group. Locked or expired, sure, but it's still there.
That defies the expected behavior of the package manager. When you start turning users and groups into packages, the abstraction needs to hold. For other packages, if I remove them everything that the package owned is gone. Some exceptions like virtuals and the kernel packages exist, but they have well-defended and mostly obvious reasons for doing what they do. You want the sources around for a kernel, even if you remove the package. You still want Apache or lighttpd even if you remove the virtual. Why would you still want a user or group after you've explicitly told your system to get rid of it?
I suspect part of this change is to increase inter-operability with other distros, but I'm struggling to think of a use case where two different distros need access to the same files but have conflicting internal IDs. I'm also struggling to figure out why Gentoo needs to do this sort of work; I'm unaware of other distros that go to great lengths to be filesystem-level-compatible with other distros. Who needs users and groups split into their own packages?
I'm going to assume that since Mgorny wrote the GLEP and pushed it forward that he ran into something that bugged him and wanted to "fix" it, but as usual he doesn't share the problem it fixes for him or anything. Having some context for these changes goes a long way to building trust in your users. This isn't about mgorny in particular, for the record. It's about changes with questionable value occurring across the tree and insufficient resources being put into messaging, migration, and long-term suitability of the solution.
Although, a brief look at the list of GLEPs shows you how effective one person is in steering Gentoo. But of course, that's all by accident, right? There's no way someone could become friends with a decision-making body and influence their decisions, right? Forgive me if I judge an organization by their decisions.
Nice Bugzilla joke.  It still isn't fixed afaict. Must be one of the longest standing infra bugs. I assure you my feelings aren't hurt over your bug tracker having half of its effective ID scope. Not my infra, not my problem.
However, a developer (or three, or seven) allowing widespread, half-baked solutions into the tree does affect me, and all other Gentoo users. Whether or not that scores on Gentoo's list of priorities is another topic. |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun Aug 11, 2019 2:19 am Post subject: |
|
|
(Double-posting to separate concerns)
@asturm:
If you want a serious, concrete answer, here's a list of distros I would check, if I was the type of developer to blindly follow another distro's number choice, without the history and context of their decision to go along with it. The first list are more common ones:
- Arch (maybe; they tend to agree with Red Hat as an upstream but differ from time to time)
- Debian (covers *buntu, Mint, etc for the most part)
- Fedora/Red Hat (800lb gorilla)
- CentOS (to see if the community corrected anything from RH)
- SuSE (sometimes they differ from Red Hat)
- Slackware (the oldest distro that's still active; good for context)
And these are to check how broad a number choice may be, or how differently other distros are approaching it:
- CRUX
- Gobolinux
- AntiX
- Puppy
- Slax
- <insert other smaller distro here>
Essentially, I'd try to put together a list of distros that are either the origin of a line (Debian -> Ubuntu -> *buntu, etc) or differ enough from their upstream to where they only share a package manager. If the goal is simply to follow, then the most common number found among peers should be chosen to maximize compatibility. If I was in the driver's seat, I'd add "defensible" as a qualifier so we're sure the decision is being made with *some* reasoning. Distros are a diverse bunch and they rotate with the seasons (i.e. what's popular today won't be so ten years from now), so IMO if you're going to copy someone you should make sure you're copying a good decision that is relevant to your own use-cases, be they personal use-cases or use cases that you're targeting with your work.
These strike me as obvious steps to take when deciding something as over-arching as user/group allocation for a distribution. Especially one that calls itself a meta-distribution. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Aug 11, 2019 2:59 am Post subject: |
|
|
| spork_kitty wrote: | | something as over-arching as user/group allocation for a distribution |
It's a list of numbers.
Before they were allocated at random. There was nothing over-arching about it, because people quite literally Did Not Give A Shit about what they were doing.
Now they might work over a reinstall, NFS, or dual-boot.
If you feel the sanctity of your bloodline is being incorrigibly defiled by having Bytes Of The Wrong Colour imported from Foreigners, maybe you might find a distro like 9front more to your liking.
Or if you insist on staying and making noise, patches welcome. "Meta-distribution" doesn't mean a distribution dictated by navel-gazing bureaucracy and 10-page rants over a friggin' config file. |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun Aug 11, 2019 3:18 am Post subject: |
|
|
| Ant P. wrote: | | spork_kitty wrote: | | something as over-arching as user/group allocation for a distribution |
It's a list of numbers.
Before they were allocated at random.
Now they might work over a reinstall, NFS, or dual-boot.
If you feel the sanctity of your bloodline is being incorrigibly defiled by having Bytes Of The Wrong Colour imported from Foreigners, maybe you might find a distro like 9front more to your liking.
Or if you insist on staying and making noise, patches welcome. |
You asked for sources, I politely obliged and provided sources. You provided no counter-argumentation or contradictory sources to dispute what I provided. Now, in your first reply, you provide trolling, to minimize the subject and mock me and the points I've made. Make up your mind on how you intend to interact with me; what was the point of asking for sources if you had no intent to examine them or discuss the subject honestly?
If you have nothing of substance to add to the thread, the back button is readily available to you. I, too, can be dismissive and flippant. I don't appreciate someone being rude to me after I spent time out of my day to share the information that I found (that said person asked for!) in an earnest effort to make discussion.
If you instead have some insight into the problem or the decisions made by Gentoo, or your own opinion on the situation to offer, then naturally we'd be inclined to read it. You use Gentoo too, right?
Somebody clean up the vomit in the aisle... |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Sun Aug 11, 2019 6:24 am Post subject: |
|
|
Merged spork_kitty's thread which begins here on the previous page. Fits better here since it is more discussion that support.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Sun Aug 11, 2019 6:27 am Post subject: |
|
|
| asturm wrote: | | pjp wrote: | | Local overrides as other items are locally overriden. /etc/portage? |
It's better than what we had prior to acct-*/*, but now you need to extend PMS, need a new EAPI, and need to setup a mechanism external to portage to distribute your custom IDs. All that to avoid a few dozen packages added to tree that work for all EAPIs and all PMs? There will have been other arguments on the list, but I didn't follow that discussion too closely. |
acct-*/* seems like the easy way. Fine. Using existing methodologies such as /etc/portage seems like a better solution. But whatever. I don't think any amont of discussion would change that since there seems little interest in mitigating impact of change, nevermind the change itself.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Juippisi
Developer
Joined: 30 Sep 2005
Posts: 753
Location: /home
|
| Posted: Sun Aug 11, 2019 6:29 am Post subject: |
|
|
What's wrong with doing things the same way as other major distributions do? Not feeling unique enough with Gentoo? :\
You can't deny that Arch has a large and active userbase, I don't think Gentoo should "look the other way".
And Gentoo still does have an option to use openrc.
| Quote: | | Please, someone, tell me how this is supposed to be a good change. From my vantage point, I see it slowing down dependency resolution, slowing down updates, and adding complexity to a part of the system that's complex enough already. |
As a maintainer this IS good change. I don't think it slows down portage or updates, unless those 2 seconds where a virtual package is merged FOR THE FIRST TIME are precious to you. As a maintainer I also feel like it takes away complexity from ebuilds, making maintenance easier in the long run for me. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Sun Aug 11, 2019 6:31 am Post subject: |
|
|
| pjp wrote: | | acct-*/* seems like the easy way. Fine. |
It's not just easier, it is also more powerful if you need to make changes in the future - think versioning. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Sun Aug 11, 2019 7:13 am Post subject: |
|
|
I accept that no amount of discussion will change the implementaiton. I'll avoid it as long as possible.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 340
|
| Posted: Sun Aug 11, 2019 7:46 am Post subject: |
|
|
| Juippisi wrote: | What's wrong with doing things the same way as other major distributions do? Not feeling unique enough with Gentoo? :\
You can't deny that Arch has a large and active userbase, I don't think Gentoo should "look the other way".
And Gentoo still does have an option to use openrc.
As a maintainer this IS good change. I don't think it slows down portage or updates, unless those 2 seconds where a virtual package is merged FOR THE FIRST TIME are precious to you. As a maintainer I also feel like it takes away complexity from ebuilds, making maintenance easier in the long run for me. |
Why do I feel a simmering anger when I read such assertions?
I thought OpenRC is our default init, and systemd is an option for the normies among us who assume that popularity is a measure of goodness.
| pjp wrote: | | ...no amount of discussion will change the implementaiton. I'll avoid it as long as possible. |
My exact thoughts. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Sun Aug 11, 2019 7:50 am Post subject: |
|
|
| proteusx wrote: | | Why do I feel a simmering anger when I read such assertions? |
Because you can't help yourself when you read the word starting with s... ending with ...d, but this was clearly in-response-to Arch being used for ID lookups and nothing else, picking on it offtopic anyway. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Aug 11, 2019 10:22 am Post subject: |
|
|
| pjp wrote: | | But whatever. I don't think any amont of discussion would change that since there seems little interest in mitigating impact of change, nevermind the change itself. |
"Surprise, surprise, surprise" done in my best Jim Nabor voice.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Last edited by Anon-E-moose on Sun Aug 11, 2019 10:36 am; edited 2 times in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Aug 11, 2019 10:29 am Post subject: |
|
|
| Juippisi wrote: | | As a maintainer this IS good change. I don't think it slows down portage or updates, unless those 2 seconds where a virtual package is merged FOR THE FIRST TIME are precious to you. |
It's taking progressively longer to run a simple check "emerge -pvuDU @world" just to have it report that absolutely nothing needs to be emerged.
If it's not that more packages are added to make it longer to churn through everything, then do you think it's caused by sunspots.
Note: it's not that acct* stuff is that much but when you add all the useless virtual's along with it and a few other things, it all adds up.
| Quote: | | As a maintainer I also feel like it takes away complexity from ebuilds, making maintenance easier in the long run for me. |
And how is that, you take the enewgroup stuff from out of one ebuild, create a new ebuild (because you're making a new group) and this is easier maintenance?
Your idea of easier and mine don't seem to jive.
I can certainly see how creating two things to look at and modify is less complex than having it all in one file.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Juippisi
Developer
Joined: 30 Sep 2005
Posts: 753
Location: /home
|
| Posted: Sun Aug 11, 2019 11:36 am Post subject: |
|
|
| Anon-E-moose wrote: |
And how is that, you take the enewgroup stuff from out of one ebuild, create a new ebuild (because you're making a new group) and this is easier maintenance?
|
| Code: |
/usr/portage $ grep -r "enewuser git" | wc -l
25
|
(from _different_ packages)
| Quote: |
Your idea of easier and mine don't seem to jive.
|
We are all entitled to an opinion and this is a subjective feeling. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
