Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
GLEP 81: User and group management via dedicated packages
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3, 4, 5, 6, 7  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18593

PostPosted: Sun Jul 28, 2019 5:49 am    Post subject: GLEP 81: User and group management via dedicated packages Reply with quote

asturm in New Systemd packages? wrote:
User and group management via dedicated packages
GLEP 81


https://packages.gentoo.org/categories/acct-group
https://packages.gentoo.org/categories/acct-user

Looks interesting. I'm not sure I like the "users tracked as a package" concept, but it certainly seems like an "easy" method to integrate.
_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18593

PostPosted: Wed Jul 31, 2019 2:49 am    Post subject: Reply with quote

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

*sigh*

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

Code:
$ diff /usr/portage/sys-fs/eudev/eudev-3.2.5.ebuild /var/db/pkg/sys-fs/eudev-3.2.5/eudev-3.2.5.ebuild

1c1
< # Copyright 1999-2019 Gentoo Authors
---
> # Copyright 1999-2018 Gentoo Foundation
8c8
< inherit autotools linux-info multilib multilib-minimal
---
> inherit autotools linux-info multilib multilib-minimal user
42,44d41
<       acct-group/input
<       acct-group/kvm
<       acct-group/render
189a187,192
>       # https://cgit.freedesktop.org/systemd/systemd/commit/rules/50-udev-default.rules?id=3dff3e00e044e2d53c76fa842b9a4759d4a50e69
>       # https://bugs.gentoo.org/246847
>       # https://bugs.gentoo.org/514174
>       enewgroup input
>
>       # REPLACING_VERSIONS should only ever have zero or 1 values but in case it doesn't,

_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7972
Location: Austria

PostPosted: Wed Jul 31, 2019 7:49 am    Post subject: Reply with quote

Well, RDEPEND changes would certainly require revbumps.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Wed Jul 31, 2019 9:23 am    Post subject: Reply with quote

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, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon


Last edited by Anon-E-moose on Wed Jul 31, 2019 5:05 pm; edited 2 times in total
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Wed Jul 31, 2019 9:36 am    Post subject: Reply with quote

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

*sigh*

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

Code:
$ diff /usr/portage/sys-fs/eudev/eudev-3.2.5.ebuild /var/db/pkg/sys-fs/eudev-3.2.5/eudev-3.2.5.ebuild

1c1
< # Copyright 1999-2019 Gentoo Authors
---
> # Copyright 1999-2018 Gentoo Foundation
8c8
< inherit autotools linux-info multilib multilib-minimal
---
> inherit autotools linux-info multilib multilib-minimal user
42,44d41
<       acct-group/input
<       acct-group/kvm
<       acct-group/render
189a187,192
>       # https://cgit.freedesktop.org/systemd/systemd/commit/rules/50-udev-default.rules?id=3dff3e00e044e2d53c76fa842b9a4759d4a50e69
>       # https://bugs.gentoo.org/246847
>       # https://bugs.gentoo.org/514174
>       enewgroup input
>
>       # REPLACING_VERSIONS should only ever have zero or 1 values but in case it doesn't,


I just ended up putting acct-group/kvm-0 in packages.provided, and yes it's becoming a waste of time to work around these geniuses and their brilliant ideas.

Edit to add: the number they used for kvm didn't match what mine is anyway.
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon


Last edited by Anon-E-moose on Wed Jul 31, 2019 9:45 am; edited 1 time in total
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7972
Location: Austria

PostPosted: Wed Jul 31, 2019 9:41 am    Post subject: Reply with quote

Anon-E-moose wrote:
Edit to add: from the glep "Michał Górny" ... why am I not surprised, this guy is a walking disaster for gentoo, he comes up with the stupidest things to implement.
And this is the genius that whines about bad advice on forums. :roll:

Can you come up with an actual case against this GLEP instead of a random smear? It's not like mgorny is responsible for the commits that added it to sys-fs/eudev or app-emulation/qemu without revbump.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Wed Jul 31, 2019 9:52 am    Post subject: Reply with quote

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, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7972
Location: Austria

PostPosted: Wed Jul 31, 2019 9:54 am    Post subject: Reply with quote

Anon-E-moose wrote:
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?

So basically your criticism is: Don't throw new packages at me? The new categories are a means to an end of uncontrolled 'silent' activation as part of the ebuilds. If there are users with an inherent distrust against the package management, they have always been able to look at a new package's ebuild whether it has been a new library dependency or a new accnt-*/ package.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Wed Jul 31, 2019 10:08 am    Post subject: Reply with quote

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, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7972
Location: Austria

PostPosted: Wed Jul 31, 2019 10:12 am    Post subject: Reply with quote

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.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Wed Jul 31, 2019 10:19 am    Post subject: Reply with quote

asturm wrote:
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.


So installing a new package based on an already installed package doesn't require user action? Interesting!!!

But ignoring that, since this was attached to a GLEP and it's being rolled out, I think it does warrant a news item.
I know you disagree, but it's not an uncommon attitude that the end-users don't matter and they should just shut up and do whatever the devs have decided.
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7972
Location: Austria

PostPosted: Wed Jul 31, 2019 10:22 am    Post subject: Reply with quote

Anon-E-moose wrote:
So installing a new package based on an already installed package doesn't require user action? Interesting!!!

Yeah... the package manager is installing it for you, just like any other dep.

It should be noted that Gentoo users already get an unparalleled level of information through their package manager when compared to the average binary distribution. You could argue that those who want to know more than is strictly necessary to keep a Gentoo installation running, or be informed even ahead of changes planned, can simply read gentoo-dev and gentoo-proj mailing list.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Wed Jul 31, 2019 10:47 am    Post subject: Reply with quote

asturm wrote:
Anon-E-moose wrote:
So installing a new package based on an already installed package doesn't require user action? Interesting!!!

Yeah... the package manager is installing it for you, just like any other dep.


Which goes to the question I asked earlier, do you just install whatever comes along without checking why it's being installed?
To me that's a recipe for disaster, but to each his own.

Quote:
It should be noted that Gentoo users already get an unparalleled level of information through their package manager when compared to the average binary distribution. You could argue that those who want to know more than is strictly necessary to keep a Gentoo installation running, or be informed even ahead of changes planned, can simply read gentoo-dev and gentoo-proj mailing list.


Ah, yes, now I need to follow the devs around just to see what they're foisting on the end user population.
Thank god we don't have a news dissemination utility, because that would just be too easy to use to let us know what's going on. :roll:

And comparing a source based distro and a binary distro is ... well, apples and oranges.

To me this is just another reminder that the devs think they're the rulers and the end users are the plebs. And your arguments just reinforce that view.

Oh well, not like I expect things to get better.

Edit to add: I should add, that I don't think all devs have the above thought process, but I've seen a handful that do exhibit it.
I think highly of the devs in general, so don't take my opinions the wrong way.
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon


Last edited by Anon-E-moose on Wed Jul 31, 2019 1:33 pm; edited 1 time in total
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 521
Location: NRW, Germany

PostPosted: Wed Jul 31, 2019 10:50 am    Post subject: Reply with quote

What the fuck are you on about Moose?
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18593

PostPosted: Wed Jul 31, 2019 3:57 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I've seen the devs do this stupid stuff before.
Have you never done "stupid stuff"?

Anon-E-moose wrote:
Just another sign of devs with too much time on their hands and too little intelligence.

Anon-E-moose wrote:
this guy is a walking disaster for gentoo, he comes up with the stupidest things to implement.
And this is the genius that whines about bad advice on forums. :roll:
Criticism of technical choices or details of implementation, etc., is acceptable, but stop the personal attacks. They are not constructve in any way. This is a warning.
_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18593

PostPosted: Wed Jul 31, 2019 4:26 pm    Post subject: Reply with quote

asturm wrote:
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.
My primary concern was the lack of a revision bump. But that is probably because I became aware of the GLEP and impending changes before I encontered them on one of my systems. Othewise, I might have preferred a news announcement for this.

I can expect general package upgrades to work when they are arch stable in the tree, but I'm still generally aware that it is still an upgrade, and something could break.

When the manner in which management of system accounts is changed, there is a strong suggestiong that <something> could go wrong and impact system stability. Maybe that is truly technically not possible, but it has the appearance that it might. It doesn't seem unreasonable to expect a short explanation of the change, a reference to the GLEP (which is short on detail, perhaps because this still seems experimental) and an explanation of why nothing could cause a problem for system stability.
Unintended removal of a user account by means of uninstalling a package seems like a credible concern. I'm leery of strong assertions that nothing can break when experimental changes are involved. After I first read the GLEP, I thought it seemed like a change for some day to come when it is ready. So I was very surprised when it came on my next sync of the tree.

asturm wrote:
It should be noted that Gentoo users already get an unparalleled level of information through their package manager when compared to the average binary distribution. You could argue that those who want to know more than is strictly necessary to keep a Gentoo installation running, or be informed even ahead of changes planned, can simply read gentoo-dev and gentoo-proj mailing list.
Excellent point about the level of information available. I wonder if this is somewhat a natural "necessity" for a rolling release? The few times I've enocountered something for which I thought a news item was warranted when one was not provided, I believe they would have made most software release lists of "release notes" or "errata."

My concern with your recommendation for reading the mailing lists as a solution is the potential volume of mail. I'll try reading them to see if it is manageable. Thanks for the suggestion.
_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Wed Jul 31, 2019 5:03 pm    Post subject: Reply with quote

pjp wrote:
but stop the personal attacks. They are not constructve in any way. This is a warning.


I edited my post earlier to add an apology, as it was indeed overboard on my part. And with that I'll bow out of this thread.
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18593

PostPosted: Wed Jul 31, 2019 6:46 pm    Post subject: Reply with quote

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

Thank you for apologizing.
_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Wed Jul 31, 2019 7:01 pm    Post subject: Reply with quote

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, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18593

PostPosted: Wed Jul 31, 2019 7:40 pm    Post subject: Reply with quote

Anon-E-moose wrote:
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.
My initial reaction is that the implimentation of individual group/user packages seems very strange and perhaps not the best method. I'm not familiar with the specific script, but the concept seems "better" if for no other reason that being simpler.

At the same itme, I see a problem with a script solution. How does the script know what users should exist? An ebuild could contain "LIST_O_USERS=audio" or something, but that script then needs to interrogate something to make that verification. While strange, the acct-group/user solution makes some sense from the standpoint that it is easy to implement using existing functionality. That has at least some merit.

Anon-E-moose wrote:
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.
I presumed you didn't think that, but prefer to make it explicit in the interest of clarity. That kind of response isn't uncommon when "moderation happens" :)
_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16187

PostPosted: Thu Aug 01, 2019 1:48 am    Post subject: Reply with quote

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."
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18593

PostPosted: Thu Aug 01, 2019 3:59 am    Post subject: Reply with quote

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.
_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4995
Location: Dallas area

PostPosted: Thu Aug 01, 2019 9:52 am    Post subject: Reply with quote

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.

Code:
    # check for ACCT_GROUP_ID collisions early
    if [[ -n ${ACCT_GROUP_ENFORCE_ID} ]]; then
        local group_by_id=$(egetgroupname "${ACCT_GROUP_ID}")
        local group_by_name=$(egetent group "${ACCT_GROUP_NAME}")
        if [[ -n ${group_by_id} ]]; then
            if [[ ${group_by_id} != ${ACCT_GROUP_NAME} ]]; then
                eerror "The required GID is already taken by another group."
                eerror "  GID: ${ACCT_GROUP_ID}"
                eerror "  needed for: ${ACCT_GROUP_NAME}"
                eerror "  current group: ${group_by_id}"
                die "GID ${ACCT_GROUP_ID} taken already"
            fi
        elif [[ -n ${group_by_name} ]]; then
            eerror "The requested group exists already with wrong GID."
            eerror "  groupname: ${ACCT_GROUP_NAME}"
            eerror "  requested GID: ${ACCT_GROUP_ID}"
            eerror "  current entry: ${group_by_name}"
            die "Group ${ACCT_GROUP_NAME} exists with wrong GID"
        fi
    fi


So, I just added all the acct-group/user ebuilds to the package.provided file. That way it won't even look at the ebuild or associated eclass.
(Yes, I did check all the rest of stuff in group/user and they were set properly, well at least according to them)

My other problem with adding yet more ebuilds, is the more ebuilds added the longer it takes to churn through them to tell me what needs to be emerged, the same applies to all the "virtuals" that seemed to be in vogue a year or two ago. Over time (multiple years) it's taking longer for emerge -pv @world to run and tell me what needs to be done, and for those with even slower systems than me, it's an even more tedious process. None of this particularly about this GLEP, just a general observation.


pjp wrote:
At the same itme, I see a problem with a script solution. How does the script know what users should exist? An ebuild could contain "LIST_O_USERS=audio" or something, but that script then needs to interrogate something to make that verification. While strange, the acct-group/user solution makes some sense from the standpoint that it is easy to implement using existing functionality.


I thought about this a little yesterday, and it would be easy enough to check /var/db/pkg/<whatever> to see if something is installed, lets take mail group for example, check for /var/db/pkg/mail-mta/* and if there then do check on mail group/user(if needed). I still prefer the script approach as it's a one time run thing vs adding ebuilds that will constantly be checked (even if not executed) thus slowing down the emerge process (see earlier comment). I may get bored enough one day to sit down and create a script that combines all acct-group/user stuff into it, just to see how easy or unwieldy it will get. Maybe I'll change my mind then.
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7972
Location: Austria

PostPosted: Thu Aug 01, 2019 9:56 am    Post subject: Reply with quote

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.

Anon-E-moose wrote:
My other problem with adding yet more ebuilds, is the more ebuilds added the longer it takes to churn through them to tell me what needs to be emerged, the same applies to all the "virtuals" that seemed to be in vogue a year or two ago.

That's assuming regular dependency relations are the reason for portage being slow; but these are straightforward deps that are not as expensive as e.g. slot operators. The real solution to that, of course, is to improve/replace portage.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18593

PostPosted: Thu Aug 01, 2019 7:32 pm    Post subject: Reply with quote

Anon-E-moose wrote:
So, I just added all the acct-group/user ebuilds to the package.provided file. That way it won't even look at the ebuild or associated eclass.
(Yes, I did check all the rest of stuff in group/user and they were set properly, well at least according to them)
I probably ought to check and see if it would cause problems, but I've got other stuff I need and would rather do. I just went with a brute force block of the modified ebuild and the acct-* dependencies. I'll see about trying the provided method.

Anon-E-moose wrote:
My other problem with adding yet more ebuilds, is the more ebuilds added the longer it takes to churn through them to tell me what needs to be emerged, the same applies to all the "virtuals" that seemed to be in vogue a year or two ago. Over time (multiple years) it's taking longer for emerge -pv @world to run and tell me what needs to be done, and for those with even slower systems than me, it's an even more tedious process. None of this particularly about this GLEP, just a general observation.
No disagreements, only that my first reaction was to not "prematurely optimize."

Anon-E-moose wrote:
I thought about this a little yesterday, and it would be easy enough to check /var/db/pkg/<whatever> to see if something is installed, lets take mail group for example, check for /var/db/pkg/mail-mta/* and if there then do check on mail group/user(if needed). I still prefer the script approach as it's a one time run thing vs adding ebuilds that will constantly be checked (even if not executed) thus slowing down the emerge process (see earlier comment). I may get bored enough one day to sit down and create a script that combines all acct-group/user stuff into it, just to see how easy or unwieldy it will get. Maybe I'll change my mind then.
In general it seems a better first option is to "work with existing primary tools" rather than an independent script. Lacking a specific script with definable advantages, integration seems a greater advantage to me, even with the drawbacks.

asturm wrote:
You should really dive into the relevant gentoo-dev thread that has all this discussed.
Starting with [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages.
I've already had a reactoin, but I'm keeping in mind that it was a discussion. :)
_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2, 3, 4, 5, 6, 7  Next
Page 1 of 7

 
Jump to:  
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