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 Previous  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
Anon-E-moose
Advocate
Advocate


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

PostPosted: Sun Aug 11, 2019 12:03 pm    Post subject: Reply with quote

Juippisi wrote:
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)


Different versions of three packages. :wink:

So now those 25 packages, are edited to remove "enewuser git" and you add acct-user to the ebuild and a package to acct-user category or the next ebuild created, you've substituted acct-user for enewuser , I still don't see easier maintenance, or less complexity, because ultimately enewuser will be called whether directly or by acct-user.eclass. And once a user/group is created it's not like they're going to be changed on a whim.

What it does do is to centralize group/user id's. But given that most new ebuilds are copies of older ones with a few changes, the end result is not that different.

Anyway not worth arguing over, as I doubt either of our minds will be changed by it. And as you say this is just my opinion and subjective feeling.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5661
Location: Removed by Neddy

PostPosted: Sun Aug 11, 2019 12:41 pm    Post subject: Reply with quote

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


Different versions of three packages. :wink:

So now those 25 packages, are edited to remove "enewuser git" and you add acct-user to the ebuild and a package to acct-user category or the next ebuild created, you've substituted acct-user for enewuser , I still don't see easier maintenance, or less complexity, because ultimately enewuser will be called whether directly or by acct-user.eclass. And once a user/group is created it's not like they're going to be changed on a whim.

What it does do is to centralize group/user id's. But given that most new ebuilds are copies of older ones with a few changes, the end result is not that different.

Anyway not worth arguing over, as I doubt either of our minds will be changed by it. And as you say this is just my opinion and subjective feeling.


the best bit is acct-user.eclass calls enewuser :lol: :lol: :lol:

Now if additional checks were needed, why not add it to enewuser method rather than the route taken. The more I look over the ML, the minutes, the code and more I hear the response from those defending the deployed implementation... the more I believe this is suffering from second system effect... Something that could be simple and elegant has been compounded by past issues faced conflating this implementation. Had any form of RRCA been performed on issues then maybe just maybe the true problem could have been defined and a more elegant solution identified
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5859

PostPosted: Sun Aug 11, 2019 3:25 pm    Post subject: Reply with quote

I'd like to hear a valid point of opposition from someone that actually contributes anything to Gentoo in the areas affected by this change. So far I haven't seen a single one.
Back to top
View user's profile Send private message
spork_kitty
n00b
n00b


Joined: 05 Jul 2019
Posts: 28

PostPosted: Sun Aug 11, 2019 4:28 pm    Post subject: Reply with quote

Ant P. wrote:
I'd like to hear a valid point of opposition from someone that actually contributes anything to Gentoo in the areas affected by this change. So far I haven't seen a single one.


Or in other words, you won't accept an argument unless there's a shiny "dev" badge next to it. Pray tell, what makes a Gentoo developer more insightful to the system than a user? The devmanual and the test are available to all, and that's all you need to become a developer. Every developer started as a technically inclined user.

Note that Gentoo devs didn't have a say in this, either. Only the council did. So becoming a developer wouldn't have solved this problem to begin with.

Maybe you ought to be the one pushing forward arguments in favor of it. So far you've sat on the sidelines and heckled people, like a coward.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Sun Aug 11, 2019 5:00 pm    Post subject: Reply with quote

spork_kitty wrote:
Ant P. wrote:
I'd like to hear a valid point of opposition from someone that actually contributes anything to Gentoo in the areas affected by this change. So far I haven't seen a single one.


Or in other words, you won't accept an argument unless there's a shiny "dev" badge next to it. Pray tell, what makes a Gentoo developer more insightful to the system than a user? The devmanual and the test are available to all, and that's all you need to become a developer. Every developer started as a technically inclined user.

Note that Gentoo devs didn't have a say in this, either. Only the council did. So becoming a developer wouldn't have solved this problem to begin with.

Maybe you ought to be the one pushing forward arguments in favor of it. So far you've sat on the sidelines and heckled people, like a coward.


I think you took what he said the wrong way.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
spork_kitty
n00b
n00b


Joined: 05 Jul 2019
Posts: 28

PostPosted: Sun Aug 11, 2019 5:22 pm    Post subject: Reply with quote

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.

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.


Some more questions with the same reasoning:

* What's wrong with wearing the same clothes as everyone else?
* What's wrong with using the same software as everyone else?
* What's wrong with driving the same car as everyone else?

Arch has a meme userbase and lazy developers. They took forever to get package signing, and defer to Red Hat whenever possible. As soon as Judd Vinet stepped down, they canned their installer and sysvinit (replacing with systemd) so they could get devs hired at Red Hat. And they succeeded. (See: Tom Gunderson) I see the same writing on the wall here at Gentoo that I did at Arch back in 2012.

I'm going to try to make this as clear as possible. Distros are built by decisions. The more you defer a decision to an outside source, the less point your distro has to exist. When enough of these decisions pile up, the effective differences between systems disappears, completely defeating the point of your distribution. Your distro now looks to other distros before it's allowed to make its own decision. How long before your distro loses its identity? You cannot have an identity and simultaneously defer your decisions to someone else. Your decisions *are* your identity.

The problem with deferring decisions is that you tend to end up bound to the entity who's making the decisions. You form a dependence on the outside source for its version of truth. Do we want a Gentoo that's dependent on other distros to make decisions? I don't.

You assert that it's a good change but didn't say *why*. It slows down Portage because there are more packages and dependencies to resolve. Even on fairly modern hardware it takes over 30 seconds to resolve the dependency tree. Adding more packages to it increases the size of the data set that it must compute, slowing it down. That's a mathematical certainty, unless there's some strange land where "n+59 > n" is false.

What's more likely to be supported here is the centralized list of UIDs and GIDs. I think that's what you guys are actually defending, and it's not a bad idea if you care about the IDs themselves. But it still isn't available on a live Gentoo system to reference, and Portage is being misused to achieve the goal. The centralized list is more valuable than the kludge used to implement it.

Riddle me this: why couldn't Gentoo have put together the centralized list and then audit the tree to make sure everything's on the same page? It could have the benefit of being a single patch-set, to be merged only when it was ready. You can even keep the eclass functions. There wouldn't be an additional 59+ packages in tree, there wouldn't be any of this discussion happening, because the problem would have been solved correctly and invisibly.

Instead we have blind support from developers of a hare-brained solution who can't defend it from a technical standpoint and a council of yes-men rubberstamping the ideas of a lone dev, which got us here in the first place.

How does putting this information into a secondary/tertiary package make things easier? Literally, the call to enewuser/enewgroup was just punted to another package, when it used to live in a phase (all in one file!).

I'm not sure what users you're used to dealing with, but many Gentoo users are capable of writing ebuilds and can read source code. Some of us see through the lip service.

I understand you aren't responsible for any of these decisions, so don't take any use of "you" personally. It's meant more at the decision-makers within Gentoo than just any developer. And they're dropping the ball, hard. Only time will tell us why...
Back to top
View user's profile Send private message
spork_kitty
n00b
n00b


Joined: 05 Jul 2019
Posts: 28

PostPosted: Sun Aug 11, 2019 5:44 pm    Post subject: Reply with quote

Anon-E-moose wrote:
spork_kitty wrote:
Ant P. wrote:
I'd like to hear a valid point of opposition from someone that actually contributes anything to Gentoo in the areas affected by this change. So far I haven't seen a single one.


Or in other words, you won't accept an argument unless there's a shiny "dev" badge next to it. Pray tell, what makes a Gentoo developer more insightful to the system than a user? The devmanual and the test are available to all, and that's all you need to become a developer. Every developer started as a technically inclined user.

Note that Gentoo devs didn't have a say in this, either. Only the council did. So becoming a developer wouldn't have solved this problem to begin with.

Maybe you ought to be the one pushing forward arguments in favor of it. So far you've sat on the sidelines and heckled people, like a coward.


I think you took what he said the wrong way.


How should I have interpreted it?
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5859

PostPosted: Sun Aug 11, 2019 6:18 pm    Post subject: Reply with quote

spork_kitty wrote:
Maybe you ought to be the one pushing forward arguments in favor of it. So far you've sat on the sidelines and heckled people, like a coward.

My patience with you, your wholly unearned elitist attitude, and the 10-posts single-thread throwaway account you cower behind has expired.

I do not sit on the sidelines. I infinitely outrank you, in seniority, knowledge and contributions to this distro, its community, and adjacent software.

Do not ever deign to tell me or anyone else doing the work here what to do.

STFU. *plonk*
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18051

PostPosted: Sun Aug 11, 2019 6:59 pm    Post subject: Reply with quote

Ant P. wrote:
I'd like to hear a valid point of opposition from someone that actually contributes anything to Gentoo in the areas affected by this change. So far I haven't seen a single one.
Yeah, my bad. Not being a developer, I really have no business expressing frustration with changes that negatively impact the systems I use. As my direct contributions are only to those specific systems, I'll refocus expression of those frustrations to those directly involved.
_________________
Those who know what's best for us must rise and save us from ourselves.
Back to top
View user's profile Send private message
GDH-gentoo
n00b
n00b


Joined: 20 Jul 2019
Posts: 46
Location: South America

PostPosted: Sun Aug 11, 2019 7:29 pm    Post subject: Reply with quote

(Note: this is just my opinion as a Gentoo user. I had nothing to do with the decision of implementing any of this)

Naib wrote:
Take syncthing-1.2.1.ebuild
Code:
RDEPEND="acct-group/syncthing
   acct-user/syncthing
   tools? ( acct-group/stdiscosrv
      acct-group/strelaysrv
      acct-user/stdiscosrv
      acct-user/strelaysrv )
   selinux? ( sec-policy/selinux-syncthing )"


So the ebuild's already had to be edited to then depend on lots of new packages

That's about the same amount of lines that the previous version of this ebuild spent making enewuser, enewgroup, keepdir and fowners invocations. Except you now also have recorded as a PMS-style dependency the fact that users "syncthing", "stdiscosrv" and "strelaysrv" and their corresponding groups have something to do with package net-p2p/syncthing.

Naib wrote:
Now look at acct-group/syncthing-0.ebuild
Code:
inherit acct-user

DESCRIPTION="User for the system-wide net-p2p/syncthing server"
ACCT_USER_ID=499
ACCT_USER_HOME=/var/lib/syncthing
ACCT_USER_HOME_PERMS=0770
ACCT_USER_GROUPS=( syncthing )

acct-user_add_deps

It has the same information as the old eclass function invocations. All this maps to their corresponding parameters, which in turn map to account parameters and home directory permissions. It is just as readable, or maybe a bit better, because you now have environment variables with self-documenting names. You don't like UID 499 for account "syncthing"? You put a modified acct-group/syncthing ebuild in a local repository with a number you like in ACCT_USER_ID. You don't like the account's home directory? You do the same with an ACCT_USER_HOME you like.

Naib wrote:
An eclass was made and deployed purely for this

now look at acct-user.eclass
....

Well yes, a new functionality has to be implemented somewhere. Most of it went to two new eclasses.

Naib wrote:
Quite a bit of effort went into this eclass to manage this acct-user_add_deps ebuild function.

acct-user_add_deps just allows expressing group membership as bash array ACCT_USER_GROUPS, and translates it to a corresponding acct-group/* dependency:

Code:
$ emerge -ptv acct-user/syncthing

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild  N     ] acct-user/syncthing-0::gentoo  0 KiB
[ebuild  N     ]  acct-group/syncthing-0::gentoo  0 KiB

Most of the new code seems to be devoted to making it possible for acct-user/* and acct-group/* ebuilds to be simple VARIABLE=value assignments.

Naib wrote:
So if Portage (the code) was updated with such a capability and Portage (the tree) was updated with n number of packages to expose this, edits have been made. Why wasn't a sensible solution involving some simple package which installs into /var/db/... keeps track of what was added, keeps track of what needs to be added... this db as its own package could then be bumped if/when new applications need specific system users/groups.

I can't deduce from this description how a solution along those lines would work. I will point out that anything that relies on /var/db/pkg is Portage-specific. As asturm mentioned earlier, it is an implementation detail of Portage, not 'public API'. So anything that relies on it and is not part of Portage itself would have to be developed in close sync, or else it will break horribly if zmedico decides some day to change something. I will grant you that if ebuilds could use the solution just by inheriting some eclass, then no PMS update would be necessary, as eclasses are covered by the current EAPI.

Naib wrote:
*IF* this was all done with just a Portage-tree bump then there could have been some argument due to some nasty bug and the simplest way was to push out this concept which stomps on namespace (from portage perspective. That isn't the case, a half-baked solution to permit portage (the code) being aware of what usernames has been deployed and is starting to cause support queries on the forums, a medium the council didn't want because "bad advice". The irony is rich here that a concept they approved has to be supported by a medium they don't think provides technical value

I can't parse this...

Anon-E-moose wrote:
Quote:
Previously, this would have required e.g. a search ebuild by ebuild for enewuser and enewgroup calls.


Code:
grep -r "enewgroup.*input" /usr/portage/


Yep, real time consuming to figure it out

Well, of course it can be done. I used a technique like this one to see how many packages in the official repository actually hard-depended on systemd. It is ugly, the recursive grep takes a long time to complete given the repository's size, but above all, it is manual work.

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

Until now. Eclasses acct-user and acct-group can check this and cause a failure if instructed to do so via ACCT_USER_ENFORCE_ID and ACCT_GROUP_ENFORCE_ID, as mv pointed out.

Naib wrote:
the best bit is acct-user.eclass calls enewuser :lol: :lol: :lol:

But in a system fully migrated to acct-*/* packages, that would be the only instance of its use, instead of it being scattered among ebuilds.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Sun Aug 11, 2019 7:49 pm    Post subject: Reply with quote

GDH-gentoo, none of your arguments move me, and I can rebut most of them, but I find that I don't really care about this crap anymore.

The sad truth is the devs have decided to go this way and it doesn't make a bit of difference what the end users think about it, which is getting to be a typical attitude.

So I'm just going to do what I think best on my system, and as for the rest, eh, not my problem.
I'll use gentoo as long as it fits my needs and modify it when the SOP doesn't jive with my way of doing things.

Y'all have fun.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
spork_kitty
n00b
n00b


Joined: 05 Jul 2019
Posts: 28

PostPosted: Sun Aug 11, 2019 9:19 pm    Post subject: Reply with quote

Ant P. wrote:
spork_kitty wrote:
Maybe you ought to be the one pushing forward arguments in favor of it. So far you've sat on the sidelines and heckled people, like a coward.

My patience with you, your wholly unearned elitist attitude, and the 10-posts single-thread throwaway account you cower behind has expired.

I do not sit on the sidelines. I infinitely outrank you, in seniority, knowledge and contributions to this distro, its community, and adjacent software.

Do not ever deign to tell me or anyone else doing the work here what to do.

STFU. *plonk*


You don't know who I am. I have a personal overlay, too. I've fixed bugs too. While you sit here and pull rank, you still haven't addressed my sources or my argument. You and I are both irrelevant to the Gentoo fiefdom, but you sit and defend it.

I'll write what I want, to whom I want, however I want. An uppity troll who wastes the time and effort of someone else and can't address arguments is a waste of time.

Logic and reason are immune to rank. If you don't like how I'm writing to you, reexamine the order of events and piss off. Respect is earned, not given.

EDIT: you forfeited my respect when you lazily asked for sources and mocked me when I provided. When you deserve it, I'll give it. Don't ask for sources unless you're prepared to discuss the topic.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7091
Location: Austria

PostPosted: Mon Aug 12, 2019 5:45 am    Post subject: Reply with quote

Anon-E-moose wrote:
GDH-gentoo, none of your arguments move me, and I can rebut most of them, but...

That's disappointing, lazy, and frankly rather disrespectful to anyone taking you seriously in this discussion, thinking you were just holding back any substantial argument so far. That last bit is now settled at least.
_________________
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
proteusx
Apprentice
Apprentice


Joined: 21 Jan 2008
Posts: 243

PostPosted: Wed Aug 14, 2019 8:10 am    Post subject: Reply with quote

From now on every time I sync I do this:

Code:
find /usr/portage/acct-user/* -type d |grep -v systemd | sed 's#/usr/portage/##' \
| sed 's/$/-0/' > /etc/portage/profile/package.provided/acct-user.provided

find /usr/portage/acct-group/* -type d |grep -v systemd | sed 's#/usr/portage/##' \
| sed 's/$/-0/' > /etc/portage/profile/package.provided/acct-group.provided

rm -r /usr/portage/acct-{user,group}


I only wish I wouldn't have to do such things.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18051

PostPosted: Wed Aug 14, 2019 8:28 pm    Post subject: Reply with quote

Is adding "-0" necessary (I rarely if ever have used provided)?
_________________
Those who know what's best for us must rise and save us from ourselves.
Back to top
View user's profile Send private message
Gatsby
n00b
n00b


Joined: 18 Jan 2010
Posts: 65
Location: 127.0.0.1

PostPosted: Wed Aug 14, 2019 9:38 pm    Post subject: Reply with quote

Yes, a version is obligatory.
_________________
Γνωθι σεαυτον.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13997

PostPosted: Thu Aug 15, 2019 1:50 am    Post subject: Reply with quote

Use of grep | sed | sed is not, however. That could all be done in one sed. That find is wrong too. It only works so long as no one adds subdirectories under the acct-* packages. As soon as a files/ directory appears, the output becomes wrong.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18051

PostPosted: Thu Aug 15, 2019 2:22 am    Post subject: Reply with quote

Hmm, just for the heck of it (although I don't see the added value):
Code:
find /usr/portage/acct-{group,user}/ -maxdepth 1 -mindepth 1 -type d |sed -e '/systemd/d' -e 's#/usr/portage/##' -e 's/$/-0/'

_________________
Those who know what's best for us must rise and save us from ourselves.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Thu Aug 15, 2019 9:10 am    Post subject: Reply with quote

Code:
find /usr/portage/acct* -name \*ebuild -print |sed -e 's!/usr/portage/!!' -e 's!/.*/!/!' -e 's!.ebuild$!!'


edit to add: I actually like only one file "package.provided" so I have a script called filter-acct
Code:
grep -v "^acct" /etc/portage/profile/package.provided >/tmp/package.provided
find /usr/portage/acct* -name \*ebuild -print | sed -e 's!/usr/portage/!!' -e 's!/.*/!/!' -e 's!.ebuild$!!' | sort >>/tmp/package.provided
mv /tmp/package.provided /etc/portage/profile

_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
proteusx
Apprentice
Apprentice


Joined: 21 Jan 2008
Posts: 243

PostPosted: Thu Aug 15, 2019 10:26 am    Post subject: Reply with quote

Hu wrote:
Use of grep | sed | sed is not, however. That could all be done in one sed.

Like this?
Code:
find /usr/portage/acct-group/* -type d | sed -n '/systemd/!s#/usr/portage/\(.*\)$#\1-0#p'

In my final sync script I used awk instead.
Code:
find /usr/portage/acct-group/* -type d | awk -F '/' '!/systemd/{print $4"/"$5"-0"}' > \
/etc/portage/profile/package.provided/acct-group.provided

find /usr/portage/acct-user/* -type d | awk -F '/' '!/systemd/{print $4"/"$5"-0"}' > \
 /etc/portage/profile/package.provided/acct-user.provided

rm -r /usr/portage/acct-{user,group}


Hu wrote:
That find is wrong too. It only works so long as no one adds subdirectories under the acct-* packages. As soon as a files/ directory appears, the output becomes wrong.

You are correct, but I thought they will not be adding patches and resources to these "packages" any time soon. They are now probably busy contriving new categories of quasi-packages to unclutter /etc/env.d from all the files bunched at the end, under 99-* and distribute the numerical prefixes more logically. :lol:

Anyway, if files directories appear, I will add -maxdepth 1 to the find, or I will copy from Anon-E-moose's version.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Thu Aug 15, 2019 11:08 am    Post subject: Reply with quote

Just a note, if you're putting stuff in package.provided, you don't need to remove the acct-* directories/files as you are overriding them (saves write/delete if on an ssd)
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
proteusx
Apprentice
Apprentice


Joined: 21 Jan 2008
Posts: 243

PostPosted: Thu Aug 15, 2019 11:31 am    Post subject: Reply with quote

I delete them from the tree to prevent annoyances such as this one:
Code:
~ # equery u pdnsd                                                                     
!!! Ambiguous package name. Choose from:                                                           
  acct-user/pdnsd                                                                                   
  net-dns/pdnsd                                                                                     
  acct-group/pdnsd
Back to top
View user's profile Send private message
spork_kitty
n00b
n00b


Joined: 05 Jul 2019
Posts: 28

PostPosted: Sat Aug 17, 2019 5:45 pm    Post subject: Reply with quote

I'm thinking we need to target a commit in the tree from before GLEP 81 implementation and move forward from there by applying/porting GLSA updates that happened since that point to important software. We can revert the 17.1 profile while we're at it and get the symlink back, then throw in a patched OpenRC to restore separate /usr. At that point, we'll be most of the way done with mitigating these backward steps and can pick up the slack from there. We could modify enewgroup and enewuser to accept an optional numeric ID as an argument, then ship a UID/GID master file and tool to check it against the tree.

The part I haven't figured out yet is how to reverse unsymlink-lib on a 17.1 system in an easy/reliable way. Can it be done with simple deletion, profile setting, and rebuild?:

Code:

eselect profile <some 17.0 profile>
rm -r /lib /usr/lib
emerge -avuNDt @world


On amd64 systems, all 32-bit programs would be broken between the time the libs are deleted and the time emerge gets around to rebuilding them. But that's no different than unsymlink-lib; it just moves your existing libs elsewhere so you can revert if the migration fails.

---

It's clear the time for words is over; only code will get us out of this.

EDIT:

Commit db05343b074a19679bd6bf2d9116e46703c43653 (2019-06-09) is the last commit made pre-GLEP81.

Commit 592a63399b048e2d92d801ed6b5eb44cba52dc08 (2019-06-05) is the last commit made prior to the 17.1 profiles becoming stable.

If someone knows the last version of OpenRC to support separate /usr (or whatever version steveL's patches are based on) please let me know.

I'm working on a bash script (called resymlink-lib, lmao) that'll quick-and-dirty-like restore you to 17.0. If all else fails, we can archive a 17.0 stage3 and work from there until I figure out catalyst.

EDIT2: I have created a Portage snapshot from 2019-06-05 and am in the process of reverting my system to 17.0 so I can start building stages.


Last edited by spork_kitty on Sun Aug 18, 2019 7:15 pm; edited 1 time in total
Back to top
View user's profile Send private message
Morality124
n00b
n00b


Joined: 20 Feb 2018
Posts: 58

PostPosted: Sun Aug 18, 2019 5:14 pm    Post subject: Reply with quote

proteusx wrote:
In my final sync script I used awk instead.
Code:
find /usr/portage/acct-group/* -type d | awk -F '/' '!/systemd/{print $4"/"$5"-0"}' > \
/etc/portage/profile/package.provided/acct-group.provided

find /usr/portage/acct-user/* -type d | awk -F '/' '!/systemd/{print $4"/"$5"-0"}' > \
 /etc/portage/profile/package.provided/acct-user.provided

rm -r /usr/portage/acct-{user,group}


+1 for using awk.

Quote:
I delete them from the tree to prevent annoyances such as this one:


I am in disbelief over how such a blatant cause-and-effect could be overlooked, even knowing the fast-and-loose practices that have become the Gentoo development norm it sadly seems. In that light, I predict a quick fix is coming in the form of a portage patch that will automatically filter out acct-* results in those ambiguous situations. A quick and awful workaround.
Back to top
View user's profile Send private message
Morality124
n00b
n00b


Joined: 20 Feb 2018
Posts: 58

PostPosted: Sun Aug 18, 2019 9:03 pm    Post subject: Reply with quote

@proteusx

Refined your script a bit (proteus-acct-fix.sh):

Code:
#!/bin/sh

packageProvided=/etc/portage/profile/package.provided
[ -d $packageProvided ] || mkdir -pv $packageProvided

for suffix in group user
do
    find /usr/portage/acct-$suffix/* -type d | awk -F '/' '!/systemd/{print $4"/"$5"-0"}' > \
        $packageProvided/acct-$suffix.provided
    rm -r /usr/portage/acct-$suffix
done
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 Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 6 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