Re: [gentoo-dev] PSA: 13.0 profiles will be removed in a week
On Fri, 2019-06-21 at 07:54 +0100, Sergei Trofimovich wrote: > On Wed, 19 Jun 2019 15:29:33 -0400 > "Anthony G. Basile" wrote: > > > On 6/19/19 3:19 AM, Sergei Trofimovich wrote: > > > This is now tracked as https://bugs.gentoo.org/688342. I hope to get > > > at least some followup there. > > > > > > > When I try to look at that bug, it says I'm not authorized. I'm > > concerned about two remaining mips profiles (uclibc and musl) which I'm > > working to migrate to 17.0. I don't think that the removal of the 13.0 > > profiles will affect them, but I'd like to know. > > > > The reason this is taking so long is 1) mips is a ~arch profile so > > there's a lot of blockers and 2) my mips equipment is slow. > > Those don't seem to inherit releases/13.0. > > I've dropped releases/13.0 again: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d40fdcf1e4bdd370a13800e73a383537beef365a > > It it happens to break other profiles missing from profiles.desc please > shout and we'll reinstate those until they are sorted. My grep-fu tells me old hardened profiles still reference 13.0. However, I think you just want to remove them. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On Fri, 2019-06-21 at 15:02 +0300, Andrew Savchenko wrote: > On Fri, 21 Jun 2019 09:18:23 +0200 David Seifert wrote: > > On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote: > > > On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote: > > > > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote: > > > > > On 6/9/2019 7:39 AM, Michał Górny wrote: > > > > > > +Tracking of user/group usage is done through dependencies. As > > > > > > long > > > > > > +as any installed package depends on a specific user/group > > > > > > package, > > > > > > +the respective user/group is assumed to be used. If no > > > > > > package > > > > > > +requiring the specific user/group is left, the package manager > > > > > > +automatically prunes the package clearly indicating it is no > > > > > > longer > > > > > > +used. > > > > > > > > > > You cannot know when a name is "no longer used". An > > > > > administrator could > > > > > have adopted a username for other purposes. > > > > > > > > That's why we don't remove the actual user/group. However, this is > > > > a valuable information to the administrator that no package is > > > > using > > > > the user/group in question. > > > > > > So how do you propose to clean them up? Or let user systems trash > > > with unused uids/gids? The GLEP 81 only mensions some possible > > > tooling for cleanup. Is there an implementation available? I don't > > > see it within proposed patch sets. > > > > > > This GLEP should not be accepted unless all necessary tools are > > > available including a cleanup tool. > > > > > > Best regards, > > > Andrew Savchenko > > > > Strongly disagree: > > > > 1) User systems are already getting trashed. And apparently it's not a > > critical thing that prevents users from using Gentoo in practice. > > 2) A cleanup tool at best will only tell you which files you need to > > check, randomly deleting files with orphaned uids/gids is not a good > > idea. > > What will happen when some acct-*/* package will be unmerged? Will > uid/gid record and/or its files be deteleted? > They will be marked as unused, locked from access and left in system databases. It's both in the GLEP and in the implementation. All you have to do is to read before complaining. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On Fri, 2019-06-21 at 15:02 +0300, Andrew Savchenko wrote: > On Fri, 21 Jun 2019 09:18:23 +0200 David Seifert wrote: > > On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote: > > > On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote: > > > > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote: > > > > > On 6/9/2019 7:39 AM, Michał Górny wrote: > > > > > > +Tracking of user/group usage is done through > > > > > > dependencies. As > > > > > > long > > > > > > +as any installed package depends on a specific user/group > > > > > > package, > > > > > > +the respective user/group is assumed to be used. If no > > > > > > package > > > > > > +requiring the specific user/group is left, the package > > > > > > manager > > > > > > +automatically prunes the package clearly indicating it is > > > > > > no > > > > > > longer > > > > > > +used. > > > > > > > > > > You cannot know when a name is "no longer used". An > > > > > administrator could > > > > > have adopted a username for other purposes. > > > > > > > > That's why we don't remove the actual user/group. However, > > > > this is > > > > a valuable information to the administrator that no package is > > > > using > > > > the user/group in question. > > > > > > So how do you propose to clean them up? Or let user systems trash > > > with unused uids/gids? The GLEP 81 only mensions some possible > > > tooling for cleanup. Is there an implementation available? I > > > don't > > > see it within proposed patch sets. > > > > > > This GLEP should not be accepted unless all necessary tools are > > > available including a cleanup tool. > > > > > > Best regards, > > > Andrew Savchenko > > > > Strongly disagree: > > > > 1) User systems are already getting trashed. And apparently it's > > not a > > critical thing that prevents users from using Gentoo in practice. > > 2) A cleanup tool at best will only tell you which files you need > > to > > check, randomly deleting files with orphaned uids/gids is not a > > good > > idea. > > What will happen when some acct-*/* package will be unmerged? Will > uid/gid record and/or its files be deteleted? > > > 3) This proposal strictly increases the quality of Gentoo. Don't > > let > > perfect be the enemy of the good. The fact that the problem isn't > > solved to 100% doesn't mean that a solution that gets us there 85% > > should be rejected. > > > > Strongly vote +1 to merge this now. > > > > > > Best regards, > Andrew Savchenko They will remain orphaned on the file system. So again, this is in no way worse than the status quo, and given that users/groups will be managed through a package manager, tracking orphaned uids/gids is a lot better with this proposal.
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On Fri, 21 Jun 2019 09:18:23 +0200 David Seifert wrote: > On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote: > > On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote: > > > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote: > > > > On 6/9/2019 7:39 AM, Michał Górny wrote: > > > > > +Tracking of user/group usage is done through dependencies. As > > > > > long > > > > > +as any installed package depends on a specific user/group > > > > > package, > > > > > +the respective user/group is assumed to be used. If no > > > > > package > > > > > +requiring the specific user/group is left, the package manager > > > > > +automatically prunes the package clearly indicating it is no > > > > > longer > > > > > +used. > > > > > > > > You cannot know when a name is "no longer used". An > > > > administrator could > > > > have adopted a username for other purposes. > > > > > > That's why we don't remove the actual user/group. However, this is > > > a valuable information to the administrator that no package is > > > using > > > the user/group in question. > > > > So how do you propose to clean them up? Or let user systems trash > > with unused uids/gids? The GLEP 81 only mensions some possible > > tooling for cleanup. Is there an implementation available? I don't > > see it within proposed patch sets. > > > > This GLEP should not be accepted unless all necessary tools are > > available including a cleanup tool. > > > > Best regards, > > Andrew Savchenko > > Strongly disagree: > > 1) User systems are already getting trashed. And apparently it's not a > critical thing that prevents users from using Gentoo in practice. > 2) A cleanup tool at best will only tell you which files you need to > check, randomly deleting files with orphaned uids/gids is not a good > idea. What will happen when some acct-*/* package will be unmerged? Will uid/gid record and/or its files be deteleted? > 3) This proposal strictly increases the quality of Gentoo. Don't let > perfect be the enemy of the good. The fact that the problem isn't > solved to 100% doesn't mean that a solution that gets us there 85% > should be rejected. > > Strongly vote +1 to merge this now. > > Best regards, Andrew Savchenko pgpDwJ3IynjJd.pgp Description: PGP signature
Re : Re: [gentoo-portage-dev] Constraint-Based Dependency Solver for Portage: again
- Zac Medico a écrit : > It's capable of considering older versions, but maybe there's some > deficiency in the algorithm. We should analyze a specific example in > order to understand the behavior. > > Maybe you're referring to this code which forces the highest version in > the event of a conflict: > > https://gitweb.gentoo.org/proj/portage.git/commit/?id=a9064d08ef4c92a5d0d1bfb3dc8a01b7850812b0 > Yes, this seems to be the cause of the problem, thank you. For testing, I created two ebuilds (and tested with "emerge -pv --autounmask-backtrack y net-misc/pdepa"): ## net-misc/pdepa-1.0 EAPI=6 KEYWORDS="amd64" SLOT="1" IUSE="feature" REQUIRED_USE="" DEPEND="" ## net-misc/pdepa-2.0 EAPI=6 KEYWORDS="amd64" SLOT="1" IUSE="feature" REQUIRED_USE="^^ ( feature )" # feature is not set => not installable DEPEND="" Like you said, due to SLOT conflict, only net-misc/pdepa-2.0 is tried, and emerge fails. Changing the SLOT of net-misc/pdepa-2.0 to 2 "solves the issue": emerge succeeds and propose to install net-misc/pdepa-1.0 However, this solution is only local: if in net-misc/pdepa-2.0 I replace REQUIRED_USE="" # now the package has no configuration problem DEPEND="!virtual/libc" # but it conflicts with an important library then emerge fails again, saying that virtual/libc blocks net-misc/pdepa-2.0 I don't know how many actual packages cannot be installed due to this optimization. I noticed this behavior in a previous version of the portage tree, when trying to install sys-auth/polkit without configuring it: - old version: REQUIRED_USE="??( systemd consolekit )" - more recent version REQUIRED_USE="^^ ( consolekit, elogind systemd )" In practice however, this was not a problem, as some dependencies of polkit deep in the tree did require one of ( systemd consolekit ) to be set. If you want, I can implement a test that check if this optimization is a problem in practice. Checking the issue shouldn't be too difficult (I think I just need to check that all REQUIRED_USE and *DEPEND are equivalent for a SLOT). Best, Michael
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
Hi,
On 2019/06/21 07:59, Andrew Savchenko wrote:
On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:
On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
On 6/9/2019 7:39 AM, Michał Górny wrote:
+Tracking of user/group usage is done through dependencies. As long
+as any installed package depends on a specific user/group package,
+the respective user/group is assumed to be used. If no package
+requiring the specific user/group is left, the package manager
+automatically prunes the package clearly indicating it is no longer
+used.
You cannot know when a name is "no longer used". An administrator could
have adopted a username for other purposes.
That's why we don't remove the actual user/group. However, this is
a valuable information to the administrator that no package is using
the user/group in question.
So how do you propose to clean them up? Or let user systems trash
with unused uids/gids? The GLEP 81 only mensions some possible
tooling for cleanup. Is there an implementation available? I don't
see it within proposed patch sets.
This GLEP should not be accepted unless all necessary tools are
available including a cleanup tool.
find / -{user,group} ???
For files having ownership at least.
There may well be other reasons why the user is still in use (that I
can't think of right now), but unfortunately this is what makes this so
difficult. I'd propose that some tool be used that provides hooks to
allow additional checks to be added.
Kind Regards,
Jaco
Re: [gentoo-dev] PSA: 13.0 profiles will be removed in a week
On 6/21/19 2:54 AM, Sergei Trofimovich wrote: > On Wed, 19 Jun 2019 15:29:33 -0400 > "Anthony G. Basile" wrote: > >> On 6/19/19 3:19 AM, Sergei Trofimovich wrote: >>> >>> This is now tracked as https://bugs.gentoo.org/688342. I hope to get >>> at least some followup there. >>> >> >> When I try to look at that bug, it says I'm not authorized. I'm >> concerned about two remaining mips profiles (uclibc and musl) which I'm >> working to migrate to 17.0. I don't think that the removal of the 13.0 >> profiles will affect them, but I'd like to know. >> >> The reason this is taking so long is 1) mips is a ~arch profile so >> there's a lot of blockers and 2) my mips equipment is slow. > > Those don't seem to inherit releases/13.0. > > I've dropped releases/13.0 again: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d40fdcf1e4bdd370a13800e73a383537beef365a > > It it happens to break other profiles missing from profiles.desc please > shout and we'll reinstate those until they are sorted. > They don't. I'm hoping over the weekend to move the remaining mips uclibc and musl profiles over to the 17.0 and then I'll clean up after myself. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote: > On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote: > > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote: > > > On 6/9/2019 7:39 AM, Michał Górny wrote: > > > > +Tracking of user/group usage is done through dependencies. As > > > > long > > > > +as any installed package depends on a specific user/group > > > > package, > > > > +the respective user/group is assumed to be used. If no > > > > package > > > > +requiring the specific user/group is left, the package manager > > > > +automatically prunes the package clearly indicating it is no > > > > longer > > > > +used. > > > > > > You cannot know when a name is "no longer used". An > > > administrator could > > > have adopted a username for other purposes. > > > > That's why we don't remove the actual user/group. However, this is > > a valuable information to the administrator that no package is > > using > > the user/group in question. > > So how do you propose to clean them up? Or let user systems trash > with unused uids/gids? The GLEP 81 only mensions some possible > tooling for cleanup. Is there an implementation available? I don't > see it within proposed patch sets. > > This GLEP should not be accepted unless all necessary tools are > available including a cleanup tool. > > Best regards, > Andrew Savchenko Strongly disagree: 1) User systems are already getting trashed. And apparently it's not a critical thing that prevents users from using Gentoo in practice. 2) A cleanup tool at best will only tell you which files you need to check, randomly deleting files with orphaned uids/gids is not a good idea. 3) This proposal strictly increases the quality of Gentoo. Don't let perfect be the enemy of the good. The fact that the problem isn't solved to 100% doesn't mean that a solution that gets us there 85% should be rejected. Strongly vote +1 to merge this now.
Re: [gentoo-dev] PSA: 13.0 profiles will be removed in a week
On Wed, 19 Jun 2019 15:29:33 -0400 "Anthony G. Basile" wrote: > On 6/19/19 3:19 AM, Sergei Trofimovich wrote: > > > > This is now tracked as https://bugs.gentoo.org/688342. I hope to get > > at least some followup there. > > > > When I try to look at that bug, it says I'm not authorized. I'm > concerned about two remaining mips profiles (uclibc and musl) which I'm > working to migrate to 17.0. I don't think that the removal of the 13.0 > profiles will affect them, but I'd like to know. > > The reason this is taking so long is 1) mips is a ~arch profile so > there's a lot of blockers and 2) my mips equipment is slow. Those don't seem to inherit releases/13.0. I've dropped releases/13.0 again: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d40fdcf1e4bdd370a13800e73a383537beef365a It it happens to break other profiles missing from profiles.desc please shout and we'll reinstate those until they are sorted. -- Sergei
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
Hi! On Thu, 20 Jun 2019 09:53:46 -0400 Brian Evans wrote: > > + > > +Before adding a new user and/or group, the developer must send a RFC > > +to the ``gentoo-dev`` mailing list. > > This paragraph should go away. It is a complete waste of time. > > +Requiring mailing list RFC > > +-- > > + > > +The policy explicitly requires RFC-es for new users and groups, as they > > +have global scopes and effects of mistakes while adding them are hard > > +to fix. Wider review should decrease the risk of major design mistakes. > > + > > +To provide one example, right now we have two different packages > > +creating ``git`` user and requiring a different home directory for > > +the user. As a result, the first package being installed defines > > +the actual home directory, and both technically can not be installed > > +at the same time. > > This section should go away. It is a complete waste of time. Mail list discussion may make sense only if users or groups and intended to be shared between different applications (e.g. ftp, mail, ntp). If user or group are intended to be application specific, there is no need for such discussions as they will just hinder development process. Best regards, Andrew Savchenko pgp1O4TymKEO2.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote: > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote: > > On 6/9/2019 7:39 AM, Michał Górny wrote: > > > +Tracking of user/group usage is done through dependencies. As long > > > +as any installed package depends on a specific user/group package, > > > +the respective user/group is assumed to be used. If no package > > > +requiring the specific user/group is left, the package manager > > > +automatically prunes the package clearly indicating it is no longer > > > +used. > > > > You cannot know when a name is "no longer used". An administrator could > > have adopted a username for other purposes. > > That's why we don't remove the actual user/group. However, this is > a valuable information to the administrator that no package is using > the user/group in question. So how do you propose to clean them up? Or let user systems trash with unused uids/gids? The GLEP 81 only mensions some possible tooling for cleanup. Is there an implementation available? I don't see it within proposed patch sets. This GLEP should not be accepted unless all necessary tools are available including a cleanup tool. Best regards, Andrew Savchenko pgpDkqP5Gug7l.pgp Description: PGP signature
