| View previous topic :: View next topic |
| Author |
Message |
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3487
Location: Canada
|
 Posted: Tue Aug 06, 2019 8:11 pm Post subject: |
 |
|
I don't know, just sounds suspicious, as every time control levels are multiplied |
|
| Back to top |
|
 |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Tue Aug 06, 2019 9:31 pm Post subject: |
|
|
| What's that statement even supposed to mean? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6242
Location: Dallas area
|
| Posted: Tue Aug 06, 2019 9:57 pm Post subject: |
|
|
It's just the latest attempt to make gentoo more user friendly, like RH.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23180
|
| Posted: Wed Aug 07, 2019 12:51 am Post subject: |
|
|
| By definition, ebuilds you install from the Portage tree have tremendous power over the system. If you don't want to review them before use, including the supporting files, then you must trust that the developers behind those ebuilds will not abuse that power. These new account management packages just make directly visible what ebuilds have been doing in an ad-hoc manner for years: adding the required users/groups to make various packages function. dmpogo: what about these packages worries you? |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3487
Location: Canada
|
| Posted: Wed Aug 07, 2019 6:07 am Post subject: |
|
|
| Hu wrote: | | By definition, ebuilds you install from the Portage tree have tremendous power over the system. If you don't want to review them before use, including the supporting files, then you must trust that the developers behind those ebuilds will not abuse that power. These new account management packages just make directly visible what ebuilds have been doing in an ad-hoc manner for years: adding the required users/groups to make various packages function. dmpogo: what about these packages worries you? |
I cannot say that I have a definitive opinion (just got today 12 new packages to install and it looked weird), but it looks a bit as an abuse (although maybe a working one) of a package paradigm. Will we be setting read/write/exec permissions through the packages next ? I am generally uneasy when some mechanisms are suddenly used for side purposes. I am also suspicious when different mechanism are competing to accomplish the same thing - somewhere, something is often get confused. |
|
| Back to top |
|
|
Juippisi
Developer
Joined: 30 Sep 2005
Posts: 762
Location: /home
|
| Posted: Thu Aug 08, 2019 7:01 pm Post subject: |
|
|
| dmpogo wrote: | | Will we be setting read/write/exec permissions through the packages next ? |
Many packages do this already. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Thu Aug 08, 2019 8:42 pm Post subject: |
|
|
| dmpogo wrote: | | I am also suspicious when different mechanism are competing to accomplish the same thing - somewhere, something is often get confused. |
That ship sailed over a decade and a half ago. It did not, in fact, fall off the edge of the world.
| Code: | ~ $ eix -c '\-(meta|base)$' | tail -1
Found 68 matches |
|
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3487
Location: Canada
|
| Posted: Thu Aug 08, 2019 9:31 pm Post subject: |
|
|
| Juippisi wrote: | | dmpogo wrote: | | Will we be setting read/write/exec permissions through the packages next ? |
Many packages do this already. |
I meant a package like acct-permisions/*
not that emerging package sets some premissions. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9360
|
| Posted: Thu Aug 08, 2019 9:34 pm Post subject: |
|
|
| And how would you emerge permissions. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20589
|
| Posted: Thu Aug 08, 2019 10:04 pm Post subject: Re: What are these acct-group packages ? |
|
|
Merged from this post: | dmpogo wrote: | | I guess subject says its all ... |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 340
|
| Posted: Fri Aug 09, 2019 7:00 am Post subject: |
|
|
| The addition of a whole load of acct-{group,user} pseudo-packages to the tree is a daft idea. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Aug 09, 2019 5:20 pm Post subject: |
|
|
| I didn't realise we had so many fans of static linking here. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20589
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23180
|
| Posted: Sat Aug 10, 2019 12:54 am Post subject: |
|
|
For those arguing against these packages, how do you think the developers should solve the problem that some packages need a user/group account to exist, sometimes even with a specific ID number, and that sometimes multiple packages will all want the same user/group to exist? I see three options:- The ad-hoc creation/management that was standard in ebuilds for years prior to this.
- These packages
- Write an EAPI extension that lets the ebuild describe the required account in a structured way, then switch all ebuilds that need these accounts to that EAPI, and push out to all users an updated package manager that understands the new EAPI
I'm not aware of specific problems with the ad-hoc approach, other than generally poor maintainability because you couldn't easily know which packages wanted which accounts. However, that alone seems like a substantial downside. These packages get away from the worst of that, while not requiring package manager updates. Personally, I would have liked to see this done in the package manager, but I recognize the logistics burdens involved in that and I readily accept that these packages get you most of the same benefit with far less logistics overhead. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6073
Location: Removed by Neddy
|
| Posted: Sat Aug 10, 2019 1:17 am Post subject: |
|
|
| Hu wrote: | For those arguing against these packages, how do you think the developers should solve the problem that some packages need a user/group account to exist, sometimes even with a specific ID number, and that sometimes multiple packages will all want the same user/group to exist? I see three options:- The ad-hoc creation/management that was standard in ebuilds for years prior to this.
- These packages
- Write an EAPI extension that lets the ebuild describe the required account in a structured way, then switch all ebuilds that need these accounts to that EAPI, and push out to all users an updated package manager that understands the new EAPI
I'm not aware of specific problems with the ad-hoc approach, other than generally poor maintainability because you couldn't easily know which packages wanted which accounts. However, that alone seems like a substantial downside. These packages get away from the worst of that, while not requiring package manager updates. Personally, I would have liked to see this done in the package manager, but I recognize the logistics burdens involved in that and I readily accept that these packages get you most of the same benefit with far less logistics overhead. |
I would want some architecting, some modeling, some system engineering so the end user doesn't get something like this
| Code: | # emerge syncthing
Calculating dependencies /
[ Results for search key : syncthing ]
* acct-group/syncthing
Latest version available: 0
Latest version installed: [ Not Installed ]
Size of files: 0 KiB
Homepage:
Description: Group for the system-wide net-p2p/syncthing server
License:
* acct-user/syncthing
Latest version available: 0
Latest version installed: [ Not Installed ]
Size of files: 0 KiB
Homepage:
Description: User for the system-wide net-p2p/syncthing server
License:
* net-p2p/syncthing
Latest version available: 1.2.1
Latest version installed: [ Not Installed ]
Size of files: 21,993 KiB
Homepage: https://syncthing.net
Description: Open Source Continuous File Synchronization
License: MPL-2.0
[ Applications found : 6 ]
!!! The short ebuild name "syncthing" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.
... done!
|
That is poor oversight... Signs of "I know what lets do foo" without actually modeling the problem and working through scenarios
These so called dev's are suppose to be architecting the gentoo system to be whatever the mission statement of Gentoo is. The user should not be presented with WTF????? like the FFMPEG debacle ...
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20589
|
| Posted: Sat Aug 10, 2019 2:35 am Post subject: |
|
|
| Hu wrote: | For those arguing against these packages, how do you think the developers should solve the problem that some packages need a user/group account to exist, sometimes even with a specific ID number, and that sometimes multiple packages will all want the same user/group to exist? I see three options:- The ad-hoc creation/management that was standard in ebuilds for years prior to this.
- These packages
- Write an EAPI extension that lets the ebuild describe the required account in a structured way, then switch all ebuilds that need these accounts to that EAPI, and push out to all users an updated package manager that understands the new EAPI
I'm not aware of specific problems with the ad-hoc approach, other than generally poor maintainability because you couldn't easily know which packages wanted which accounts. However, that alone seems like a substantial downside. These packages get away from the worst of that, while not requiring package manager updates. Personally, I would have liked to see this done in the package manager, but I recognize the logistics burdens involved in that and I readily accept that these packages get you most of the same benefit with far less logistics overhead. |
First, any new and experimental methodology should never have been introduced to stable systems. Second, I acknowledge that the adhoc approach being used was inadequate and worthy of a "testable" (word choice?) solution. Third, the package as a solution seems very kludgy, but may be the fastest / easiest way to implement such a solution in Gentoo. That approach has some merit, with the first issue having been addressed. Finally, I'd have to see how the issue has been addressed on other *nix operating systems to compare the solutions. It is still possible that even if this implementation is "less than ideal," that it may still be the better option.
One possible option would be a tool along the lines of the password file validator with a mapping of confiurable usernames and UIDs. A generic approach seems better than one that is distro / system specific.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Aug 10, 2019 3:35 am Post subject: |
|
|
| If we wanted this done right we'd switch to tcb shadow password files, and these packages would actually *install* (and uninstall) something that way. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20589
|
| Posted: Sat Aug 10, 2019 3:48 am Post subject: |
|
|
| Ant P. wrote: | | If we wanted this done right we'd switch to tcb shadow password files, and these packages would actually *install* (and uninstall) something that way. |
Apparently it was once possible in Gentoo...
https://www.openwall.com/tcb/ | Quote: | tcb is fully integrated into Owl, distributions by ALT Linux team, and Mandriva Linux 2009 and up (and later in Mageia). It is available for Gentoo Linux.
/etc/tcb is natively supported in musl - a lightweight libc for Linux. |
I've been thinking about trying musl.
That Gento reference: | Quote: | To use TCB under Gentoo, the packages libxcrypt and tcb need to be emerged. However, at the moment, the package tcb needs an overlay digest file to link correctly. After quickly hacking one together, I added it to an existing gentoo bug report.
With that portage overlay setup correctly, it can be emerged. |
The bug report: https://bugs.gentoo.org/161564
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 340
|
| Posted: Sat Aug 10, 2019 4:04 am Post subject: |
|
|
So from now on, the maintainer of say, qemu, besides app-emulation/qemu is required to create and take care of acct-{user, group}/qemu.
This infantile scheme is neither efficient nor elegant.
If you must do away with the "ad-hoc" way of allocating users and groups (which worked fine for the last 18 years) why not do it wholly within the acct-{user,group}.eclass without introducing fictitious categories and packages? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6073
Location: Removed by Neddy
|
| Posted: Sat Aug 10, 2019 9:13 am Post subject: |
|
|
| pjp wrote: | | Hu wrote: | For those arguing against these packages, how do you think the developers should solve the problem that some packages need a user/group account to exist, sometimes even with a specific ID number, and that sometimes multiple packages will all want the same user/group to exist? I see three options:- The ad-hoc creation/management that was standard in ebuilds for years prior to this.
- These packages
- Write an EAPI extension that lets the ebuild describe the required account in a structured way, then switch all ebuilds that need these accounts to that EAPI, and push out to all users an updated package manager that understands the new EAPI
I'm not aware of specific problems with the ad-hoc approach, other than generally poor maintainability because you couldn't easily know which packages wanted which accounts. However, that alone seems like a substantial downside. These packages get away from the worst of that, while not requiring package manager updates. Personally, I would have liked to see this done in the package manager, but I recognize the logistics burdens involved in that and I readily accept that these packages get you most of the same benefit with far less logistics overhead. |
First, any new and experimental methodology should never have been introduced to stable systems. Second, I acknowledge that the adhoc approach being used was inadequate and worthy of a "testable" (word choice?) solution. Third, the package as a solution seems very kludgy, but may be the fastest / easiest way to implement such a solution in Gentoo. That approach has some merit, with the first issue having been addressed. Finally, I'd have to see how the issue has been addressed on other *nix operating systems to compare the solutions. It is still possible that even if this implementation is "less than ideal," that it may still be the better option.
One possible option would be a tool along the lines of the password file validator with a mapping of confiurable usernames and UIDs. A generic approach seems better than one that is distro / system specific. |
That's the thing, the need is valid and I would question anyone who didn't think so... the system needs to be aware of the needed users and groups.
| Hu wrote: |
These packages get away from the worst of that, while not requiring package manager updates. Personally, I would have liked to see this done in the package manager, but I recognize the logistics burdens involved... |
This is a valid stance and may have been one of the constraints on the implementation. "Must be deployed in present system that might not have updated portage". Personally I don't think that carries weight as something would need to be deployed for the end-user to actually change their local machine. Whats the difference between a load of acct-user/* packages or a portage bump?
Its a stance though
Option #1 in portage
Option #2 as an eclass
Option #3 acct-user/* ebuilds
Option #4 an acct-user.ebuild which installs a post-emerge hook ( into /etc/portage/bashrc ) which executes the acct-user script/program that does the check.
The ebuilds have all been bumped with additional acct-user/* packages so this already would potentially cause a re-emerge, thus the dev's cannot be adverse to that (or didn't think of this... scenarios) HENCE #1, #2, #3 all have the same end-effect for the user with #3 adding special WTF!!!! so why #3?
there is already an acct-user_add_deps functional call added, thus #1 and #2 were implemented, so why take the extra step and do #3?
On the basis that 1,2,3 were deployed it would have made sense todo 1,2,4 ... a package acting as a database of packages,user and groups.
so again... why acct-user/* ebuilds ?
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6242
Location: Dallas area
|
| Posted: Sat Aug 10, 2019 10:07 am Post subject: |
|
|
| Naib wrote: | | so again... why acct-user/* ebuilds ? |
Mostly systemd. Take a look at the ownership of most of acct-group 21/37 owned/maintained by systemd, just from that I infer that it was spearheaded by the systemd people, perhaps with input from RH/FDO (we know what's best for you) people. Although only 5/20 ownership in acct-user. They're probably doing something stupid, like not checking for name from /etc/group and just using what they think the numeric value should be and it's causing them problems, so in their usual way of doing things everyone else must suffer.
My system has been set up for a long time, and most of the users/groups match what they "created" the acct-user/group garbage to do. The only one that didn't match their pkgs, was kvm group, and it was unique, even if it wasn't what they thought it should be.
For most people when they install stage 3 they inherit a great percentage of these users/groups already set up properly.
For anything else added they don't need specific numbers, they need unique ones, other than root userid/groupid the system doesn't care what they are.
As for the name collisions I've long been aggravated by that, though I've seen haskell as the biggest offender. It's funny that they made a big deal out of openrc's binary name conflicting with a debian name, but think nothing of every haskell pkg duplicating some other name already in existence. So although it's a PITA, I've sort of become used to having to do category/pkg for lots of emerges, equeries, etc. /RANT
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
Juippisi
Developer
Joined: 30 Sep 2005
Posts: 762
Location: /home
|
| Posted: Sat Aug 10, 2019 12:27 pm Post subject: |
|
|
| proteusx wrote: | | So from now on, the maintainer of say, qemu, besides app-emulation/qemu is required to create and take care of acct-{user, group}/qemu. |
As a maintainer, I welcome this change :) in the long run it makes things easier for me, and helps to clean the ebuilds a bit.
| Quote: | | This infantile scheme is neither efficient nor elegant. |
That's like, your opinion man. I like Ferrari, you like Lamborghini? It is efficient though.
| Quote: | | If you must do away with the "ad-hoc" way of allocating users and groups (which worked fine for the last 18 years) why not do it wholly within the acct-{user,group}.eclass without introducing fictitious categories and packages? |
How'd you do that?
From what I see the biggest complaint is people whose "system installed packages" went from 499 to 505. Unbearable.
Then there's that one missed revbump and issue with synonyms on emerge, the latter I believe will be a work in progress. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6242
Location: Dallas area
|
| Posted: Sat Aug 10, 2019 1:00 pm Post subject: |
|
|
| Juippisi wrote: | | Quote: | | If you must do away with the "ad-hoc" way of allocating users and groups (which worked fine for the last 18 years) why not do it wholly within the acct-{user,group}.eclass without introducing fictitious categories and packages? |
How'd you do that? |
Modifying the way it's been done for quite a while.
Two part approach.
1. create a script to take all currently known userid/groupid and check people's /etc/passwd and /etc/group for being in "compliance" with a message/warning put out if they don't match "that unexpected things might happen if they're not fixed", and leave it to the people to change things or at least get the ok to make changes, similar to what etc-update does.
2. make a db/checklist for all future additions and use that when creating new groups/userids, again with a warning if "non-unique ids, are found"
All of which could be done from within the eclass.
| Quote: | From what I see the biggest complaint is people whose "system installed packages" went from 499 to 505. Unbearable.
Then there's that one missed revbump and issue with synonyms on emerge, the latter I believe will be a work in progress. |
While indeed there may not be a lot of complaints about it at the moment, I look at it the same way as the change from profile 17.0 to 17.1 as more and more people started upgrading the problems of a half-assed approach started appearing. I expect there to be a lot more turmoil over the next few months, rather than less.
But this is all meaningless, since the few devs that made this decision have already started down the path they're on.
Note: I've looked at the latest polkit user/group ids and they conflict with things that are already on my system (set by portage in the past), I don't use those id's anymore but I think you'll start seeing more of that, rather than less, especially with older systems.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Aug 10, 2019 2:50 pm Post subject: |
|
|
| proteusx wrote: | So from now on, the maintainer of say, qemu, besides app-emulation/qemu is required to create and take care of acct-{user, group}/qemu.
This infantile scheme is neither efficient nor elegant.
If you must do away with the "ad-hoc" way of allocating users and groups (which worked fine for the last 18 years) why not do it wholly within the acct-{user,group}.eclass without introducing fictitious categories and packages? |
And are overlays banned from adding IDs under your scheme? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6073
Location: Removed by Neddy
|
| Posted: Sat Aug 10, 2019 3:09 pm Post subject: |
|
|
| Juippisi wrote: |
From what I see the biggest complaint is people whose "system installed packages" went from 499 to 505. Unbearable.
Then there's that one missed revbump and issue with synonyms on emerge, the latter I believe will be a work in progress. |
Do you really think people are complaint about a 6 or more packages?
Do you really think the need for some form of management of user/group on a package basis isn't accepted by people?
The method being pushed is what is cause the complaints and yet again the forums and the users are going to be here to pick up the pieces..
And that latter... If it was known about, why release a half baked solution? THIS is what system engineering is about and yet again no signs of such a concept is understood.
There are soo many ways to need the use-case, why this way?
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| 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
