Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On Thu, Jun 20, 2019 at 09:53:46AM -0400, Brian Evans wrote: > What significance will such numbers have when a daemon uses a new > UID/GID and really doesn't care what it is? Why do we have to go > through the effort of assigning fixed IDs at random? One reason not mentioned by mjo: this paves the way to resolution of very old frustrating problem with user/group creation when cross-compiling entire system from scratch. See https://bugs.gentoo.org/541406 signature.asc Description: Digital signature
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: [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] [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] [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
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
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. -- 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 6/20/19 9:53 AM, Brian Evans wrote: >> + >> +Following the acceptance of this GLEP, all new users and groups must >> +be created via user/group packages as defined in this GLEP. The old >> +method may still be used for existing users/groups, in existing >> +packages. >> + >> +All new users and groups must have unique UIDs/GIDs assigned >> +by developers. The developer adding them is responsible for checking >> +for collisions. > > What significance will such numbers have when a daemon uses a new > UID/GID and really doesn't care what it is? Why do we have to go > through the effort of assigning fixed IDs at random? > People want this. Here's the thread from 2017: https://archives.gentoo.org/gentoo-dev/message/2355afd4f5b72651e2ff47ea8b10c1fe Selectively quoting: * I might be not following correctly, but due to how filesystems/etc work it is probably desirable to have consistent UID/GIDs as much as reasonably possible. -rich0 * I don't think we need to have stable UIDs/GIDs in the "normal" case of standalone users with a single Gentoo system at home. The people who need predictable UIDs/GIDs are the "enterprise" users or the home users who use things such as NFS. I work for a company that uses Gentoo, we have a bunch of workarounds to make sure that UIDs and GIDs are stable. -chutzpah * I for one am more than willing to do whatever shell commands necessary to make all my Gentoo installs agree on UIDs and get [fixed UID proposal] now, but I realise most people are not. -A. Wilcox * YES! I think after [fixed UIDs] is finalized, it should be part of the handbook installation as a default, but selectable. -james * If the user does not exist then create it. Preferably use a pre- assigned UID/GID so there is some consistency with most other Gentoo things out there. -Alan McKinnon This will make a lot of peoples' lives easier, and is very easy to do.
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On 6/9/2019 7:39 AM, Michał Górny wrote: > +Specification > += > + > +Policy > +-- > + > +Following the acceptance of this GLEP, all new users and groups must > +be created via user/group packages as defined in this GLEP. The old > +method may still be used for existing users/groups, in existing > +packages. > + > +All new users and groups must have unique UIDs/GIDs assigned > +by developers. The developer adding them is responsible for checking > +for collisions. What significance will such numbers have when a daemon uses a new UID/GID and really doesn't care what it is? Why do we have to go through the effort of assigning fixed IDs at random? > + > +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. > + > + > +Logical structure > +- > + > +In this proposal, system users and groups are represented by regular > +packages. Those packages logically represent the ownership of > +the respective users and group, and technically implement their > +creation. > + > +User packages are placed in ``acct-user`` category. Each user package > +defines the properties of the particular user, and must be named after > +the user it creates. It must depend at build and run time on the groups > +the user belongs to. > + > +Group packages are placed in ``acct-group`` category. Each group > +package defines the properties of the particular group, and must be > +named after the group it creates. > + > +All user and group packages must define preferred fixed UIDs/GIDs, > +and they must be unique within the repository. The packages should > +indicate whether the value needs to be strictly enforced, or whether > +another UID/GID is acceptable when the user exists already or requested > +UID/GID is taken. > + > +Packages needing a specific user or group use dependencies to pull > +the required user/group packages. If the user is needed at build time, > +a build time dependency (``DEPEND``) must be used. If the user is > +needed at install and/or run time, a run time dependency (``RDEPEND``) > +must be used. Sounds like extra upgrade dependency time in an already crowded resolution tree. > + > +Rationale > += > + > +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. > + > + > +Satisfied goals > +--- > + > +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. > + > +Each user and group has a single respective package creating it. > +If multiple packages need it, they depend on the same package. This > +ensures that all properties are kept in a single location, and do not > +need to be synced. > + > +Having a single location with all predefined user/group ranges makes it > +possible to maintain fixed UID/GID definitions. This GLEP makes > +allocating them obligatory. While this isn't enforced for existing > +users, it provides a way forward for new installations. > + > +Local overrides can be trivially implemented via local repository, > +through overriding the respective user/group ebuilds. The proposal also > +respects direct sysadmin modifications. > + > +Avoiding unnecessary user/group creation at build time is implemented > +via correct dependency types. While this was possible with the status > +quo, the dependency model should be more natural to developers and cause > +less mistakes. > + > + signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
On Wed, 2019-06-12 at 22:21 -0400, Michael Orlitzky wrote: > On 6/9/19 7:39 AM, Michał Górny wrote: > > + > > +All new users and groups must have unique UIDs/GIDs assigned > > +by developers. The developer adding them is responsible for checking > > +for collisions. > > > > ... > > > > +All user and group packages must define preferred fixed UIDs/GIDs, > > +and they must be unique within the repository. The packages should > > +indicate whether the value needs to be strictly enforced, or whether > > +another UID/GID is acceptable when the user exists already or requested > > +UID/GID is taken. > > + > > Maybe we should loosen this in the case of enforced UIDs. If two > user-packages truly do require the same fixed UID (for whatever godawful > reason), then obviously they can't be installed on the same machine, but > we could otherwise support both in the repository. I'd rather not permit it up front. We can revisit this if it ever becomes really necessary. > > I don't want to encourage people to add such badly-written software to > the repo, but the alternative is also pretty ugly: if we require the > UIDs to be unique, and if two packages require the same enforced UID, > then whoever commits to ::gentoo first will prevent the other guy from > adding his package later on. The alternative is to prevent user from installing the second package without manually fixing his UID/GID table. This is horrible UX. I suppose patching one of the packages to use another UID/GID is probably better. -- 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 6/9/19 7:39 AM, Michał Górny wrote: > > + > +All new users and groups must have unique UIDs/GIDs assigned > +by developers. The developer adding them is responsible for checking > +for collisions. > > ... > > +All user and group packages must define preferred fixed UIDs/GIDs, > +and they must be unique within the repository. The packages should > +indicate whether the value needs to be strictly enforced, or whether > +another UID/GID is acceptable when the user exists already or requested > +UID/GID is taken. > + Maybe we should loosen this in the case of enforced UIDs. If two user-packages truly do require the same fixed UID (for whatever godawful reason), then obviously they can't be installed on the same machine, but we could otherwise support both in the repository. I don't want to encourage people to add such badly-written software to the repo, but the alternative is also pretty ugly: if we require the UIDs to be unique, and if two packages require the same enforced UID, then whoever commits to ::gentoo first will prevent the other guy from adding his package later on.
[gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages
Changes in v3: - Added 'Policy' section. Notably, it deprecates the old method, requires RFC for new users/groups, and makes UID/GID assignment explicitly required. - Removed PDEPEND option in favor of RDEPEND. - Changed the behavior to explicitly update user/group properties on rebuild/upgrade. This is necessary to handle unlocking accounts and generally seems to make more sense. - Removed obsolete category section from rationale. -- Best regards, Michał Górny Signed-off-by: Michał Górny --- glep-0081.rst | 246 ++ 1 file changed, 246 insertions(+) create mode 100644 glep-0081.rst diff --git a/glep-0081.rst b/glep-0081.rst new file mode 100644 index 000..5bfd048 --- /dev/null +++ b/glep-0081.rst @@ -0,0 +1,246 @@ +--- +GLEP: 81 +Title: User and group management via dedicated packages +Author: Michał Górny , +Michael Orlitzky +Type: Standards Track +Status: Draft +Version: 1 +Created: 2019-05-29 +Last-Modified: 2019-06-09 +Post-History: 2019-05-29 +Content-Type: text/x-rst +Requires: +Replaces: 27 +--- + +Abstract + + +A new approach for user/group management is proposed. Regular packages +in dedicated categories are used to represent and create user and group +accounts. Dependencies are used to request users and group from within +regular packages, and to track their usage. + + +Motivation +== + +User management in Gentoo is currently ad-hoc. Users and groups are +created through calling system tools directly in packages needing them. +There is no systematic way of tracking which packages need specific +users or groups, and determining which ones are obsolete. Coordinating +properties of users and groups used by multiple packages must be done +manually by developers. + +GLEP 27 originally attempted to address the problem. Posted in 2004, +it never had reached the reference implementation state, and became +obsolete. [#GLEP27]_ + +A good system user and group management proposal should address: + +1. Tracking usage of users and groups, and determining which ones + are obsolete. + +2. Sharing users and groups reliably between different packages. + +3. Maintaining fixed UIDs/GIDs that are consistent between different + systems. + +4. Providing local overrides for user/group properties. + +5. Ensuring that users and groups are not created unnecessarily + at build time. + +6. Providing support for centralized account management (e.g. LDAP). + +At the same time, the proposal should avoid unnecessary complexity +to avoid sharing the fate of GLEP 27. This proposal aims to address +those points without requiring a new EAPI or any changes in the package +manager. + + +Specification += + +Policy +-- + +Following the acceptance of this GLEP, all new users and groups must +be created via user/group packages as defined in this GLEP. The old +method may still be used for existing users/groups, in existing +packages. + +All new users and groups must have unique UIDs/GIDs assigned +by developers. The developer adding them is responsible for checking +for collisions. + +Before adding a new user and/or group, the developer must send a RFC +to the ``gentoo-dev`` mailing list. + + +Logical structure +- + +In this proposal, system users and groups are represented by regular +packages. Those packages logically represent the ownership of +the respective users and group, and technically implement their +creation. + +User packages are placed in ``acct-user`` category. Each user package +defines the properties of the particular user, and must be named after +the user it creates. It must depend at build and run time on the groups +the user belongs to. + +Group packages are placed in ``acct-group`` category. Each group +package defines the properties of the particular group, and must be +named after the group it creates. + +All user and group packages must define preferred fixed UIDs/GIDs, +and they must be unique within the repository. The packages should +indicate whether the value needs to be strictly enforced, or whether +another UID/GID is acceptable when the user exists already or requested +UID/GID is taken. + +Packages needing a specific user or group use dependencies to pull +the required user/group packages. If the user is needed at build time, +a build time dependency (``DEPEND``) must be used. If the user is +needed at install and/or run time, a run time dependency (``RDEPEND``) +must be used. + + +Maintaining users/groups + + +The primary technical function of user and group packages is to create +the users and groups. This is done via invoking the respective system +tools at ``pkg_preinst`` phase. This is done only if the user/group +does not exist on the system already. + +If the user or group exists already, the package performs necessary +modifications in order to meet requested properties. This includes +updating user's home directory
