GLEP 81: User and group management via dedicated packages

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

Experimental features don't require a revision bump on ebuilds...

*sigh*

This garbage is taking up too much time to manage around.

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

Well, RDEPEND changes would certainly require revbumps.

Anon-E-moose · Posted: Wed Jul 31, 2019 9:23 am Post subject:

And yet this morning I get
[ebuild N ] acct-group/kvm-0::gentoo 0 KiB

for app-emulation/qemu-4.0.0-r3::gentoo which is already installed (no rev bump) :roll:

edit to remove stuff that was overboard on my part

Edit to add2: this was indeed overboard on my part, and I apologize.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

Anon-E-moose · Posted: Wed Jul 31, 2019 9:36 am Post subject:

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

Anon-E-moose · Posted: Wed Jul 31, 2019 9:52 am Post subject:

My comment had nothing to do with who added eudev/qemu w/o revbump.
Just a general comment about Gorny's track record of brilliant ideas, his name was attached to the GLEP.

And no, I have nothing against this particular GLEP, but why not just silently activate as part of the ebuilds, rather than cause people to wonder why yet another package is being pulled in, and then have to spend time looking to see what's going on. Or are you the type to just randomly install things that others want to, on your system, without seeing what it's about, because I'm not that type?
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

Anon-E-moose · Posted: Wed Jul 31, 2019 10:08 am Post subject:

Way to dance around the point, asturm :roll:

ETA: based on your original post, I see it was changed.

Why wasn't a news article attached to this new way of doing things, then I wouldn't have had to spend time seeing why something NEW was being pulled in on an ALREADY emerged ebuild.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

I can't comment on the rollout of this as I am not involved in it, but I disagree with the notion that changes that do not require user action require a news item.

Anon-E-moose · Posted: Wed Jul 31, 2019 10:19 am Post subject:

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

Anon-E-moose · Posted: Wed Jul 31, 2019 10:47 am Post subject:

Dr.Willy · Guru Joined: 15 Jul 2007 Posts: 547 Location: NRW, Germany

What the fuck are you on about Moose?

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

Anon-E-moose · Posted: Wed Jul 31, 2019 5:03 pm Post subject:

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

To be clear, I wasn't suggesting you had to stop participating.

Thank you for apologizing.
_________________
Quis separabit? Quo animo?

Anon-E-moose · Posted: Wed Jul 31, 2019 7:01 pm Post subject:

I'll add one more thing, I had it set to post earlier, but got sidetracked with other things.

Rather than a whole bunch of acct-group/acct-user packages, as a dev, I would have created a script to check all the user/group ids at once, similar to the cpu flags script, then let it be optional to check things with a news item to alert people that they might want to align groups/users ids to what is expected, if they aren't already set properly.

And that's all I have to say about this particular GLEP.
It's not because of me thinking you were suggesting I be quiet, but I've pretty much said all I have to on this subject.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

Hu · Administrator Joined: 06 Mar 2007 Posts: 21724

With regard to whether a news item is warranted: I can see the argument that this is a sufficiently invasive change that it warrants communication. On the other hand, there seems to be a general policy that news items are used for situations where the typical user likely will need to do more than just sync&&install. Looking at recent news items, we have the 17.1 profile: substantial user action required for a successful migration; change of ACCEPT_LICENSE: there was a lot of churn on the forum from people whose systems did not react perfectly smoothly to the new default; OpenSSH/LDAP: users who ignored this one, and who were affected by it, lost LDAP support in OpenSSH; Python 3.6 as default: lots of rebuilds for this. I could go on, but the general theme I get is that if these news items had not been posted, or if the user ignored them, the system would need some manual intervention and/or support from the forum. (Python is an outlier here, but the news item makes reference to potential blockers, so this may have been done as a defensive measure to cut down on the number of people asking for help resolving the dependency conflicts.)

For this account migration, the developers clearly hope that no user intervention is required. Whether the implementation will satisfy their hopes is an open question, but since they intend it to work seamlessly, and don't have any strong evidence (that I know of, at least) that it isn't, I can see not writing a news item for it.

I understand that you are concerned about new packages, especially new categories, just appearing. I find it reasonable to look into why that happened, and I did the same here because I was curious about the new categories, but since the system could work if you just accept its proposals, it doesn't rise to the level of "user intervention required."

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

My primary issue was the lack of a revision bump. And if I understood asturm's resonse, it seemed like he agreed this should have been a new revision. Since there is a choice to be made in whether or not to add a new revision and mistakes are made, maybe it is warranted that no change is performed without a revision bump. I don't see any other way to resolve the "should have, didn't" problem.

As for the news item, I can understand the position that they are only provided when user interaction is expected. And I'm expressing concern that "user intervention" is insufficient regarding new, experimental features. Although a "redo" of an earlier GLEP, this version was created in May. The "Reference Implementation" section states "Initial user and group packages have been created in order to test the concept." That last part reinforces my observation that this is "experimental." From the email, "The main change from the earlier proposal is that we are extremely careful not to break stuff." I can appreciate intent (been there, done that), but I'm not interested in testing unnanounced concepts, because intent is insufficient (also been there, done that).

Maybe these events are just an unfortunate coincidence, but I'm concerned that it seems to be in the interest of faster iteration at the expense of stability. New, experimental features typically are not (or were not) released in "stable" software. Maybe I was only lucky in having that same general experience with stable arch packages in the tree.

Over the years, I've seen others comment on needing to spend too much time maintaining their systems. Maybe I'm finally having that experience for the first time, although it isn't particularly recent. Since I converted my daily driver laptop, I have noticed it more, and I seem to get little else done in the time available. Xorg, Licenses, Python, 17.1. I'm OK with all of those. Fortunately I didn't get bit by the Xorg issue (but only because others did). Each has required a "substantial" amount of time and/or effort to investigate or address. I have the perception that there were some issues prior to the Xorg incident, but I can't recall specifics.

I also recall reading about users having various problems with perl upgrades or some other common software, but I never encountered them. I presumed it was partly due to running stable arch, but perhaps I was just lucky.
_________________
Quis separabit? Quo animo?

Anon-E-moose · Posted: Thu Aug 01, 2019 9:52 am Post subject:

I mentioned earlier that my kvm group wasn't what they use now, probably because when I first put qemu down kvm was a separate critter and I don't think it set the group (at that time).

And from looking at the the acct-group.eclass I would have had to do a manual intervention, as the emerge would have failed.

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

You should really dive into the relevant gentoo-dev thread that has all this discussed.

Regarding /var/db/pkg you can not make any assumptions about its format as it is not covered by PMS.

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067