| View previous topic :: View next topic |
| Author |
Message |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
 Posted: Sun Aug 11, 2019 12:03 pm Post subject: |
 |
|
| 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. 
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.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
 |
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sun Aug 11, 2019 12:41 pm Post subject: |
|
|
| 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.
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 
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
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Aug 11, 2019 3:25 pm Post subject: |
|
|
| 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 |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun Aug 11, 2019 4:28 pm Post subject: |
|
|
| 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 |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Aug 11, 2019 5:00 pm Post subject: |
|
|
| 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.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun Aug 11, 2019 5:22 pm 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.
| 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 |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun Aug 11, 2019 5:44 pm Post subject: |
|
|
| 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 |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Aug 11, 2019 6:18 pm Post subject: |
|
|
| 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 |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Sun Aug 11, 2019 6:59 pm Post subject: |
|
|
| 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.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1699
Location: South America
|
| Posted: Sun Aug 11, 2019 7:29 pm Post subject: |
|
|
(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 |
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 |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Aug 11, 2019 7:49 pm Post subject: |
|
|
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.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun Aug 11, 2019 9:19 pm Post subject: |
|
|
| 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 |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Mon Aug 12, 2019 5:45 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 340
|
| Posted: Wed Aug 14, 2019 8:10 am Post subject: |
|
|
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 |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Wed Aug 14, 2019 8:28 pm Post subject: |
|
|
Is adding "-0" necessary (I rarely if ever have used provided)?
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Gatsby
Tux's lil' helper
Joined: 18 Jan 2010
Posts: 121
Location: 127.0.0.1
|
| Posted: Wed Aug 14, 2019 9:38 pm Post subject: |
|
|
Yes, a version is obligatory.
_________________
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22657
|
| Posted: Thu Aug 15, 2019 1:50 am Post subject: |
|
|
| 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 |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Thu Aug 15, 2019 2:22 am Post subject: |
|
|
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/' |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Thu Aug 15, 2019 9:10 am Post subject: |
|
|
| 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 |
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 340
|
| Posted: Thu Aug 15, 2019 10:26 am Post subject: |
|
|
| 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.
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 |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Thu Aug 15, 2019 11:08 am Post subject: |
|
|
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)
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 340
|
| Posted: Thu Aug 15, 2019 11:31 am Post subject: |
|
|
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 |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sat Aug 17, 2019 5:45 pm Post subject: |
|
|
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? EDIT: It's complicated and not worth the effort; a 17.0 stage3 is faster and more-or-less guaranteed to work.
---
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.
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.
EDIT3: veremitz has generously provided a stage3 from 2018-07-26. It's only a matter of time now, boys and girls. 
Last edited by spork_kitty on Sat Sep 07, 2019 3:54 pm; edited 2 times in total |
|
| Back to top |
|
|
Morality124
Tux's lil' helper
Joined: 20 Feb 2018
Posts: 102
|
| Posted: Sun Aug 18, 2019 5:14 pm Post subject: |
|
|
| 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 |
|
|
Morality124
Tux's lil' helper
Joined: 20 Feb 2018
Posts: 102
|
| Posted: Sun Aug 18, 2019 9:03 pm Post subject: |
|
|
@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 |
|
|
|
|
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
