We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but
never implemented it. I'm wondering what are the explicit requirements
that we have for user and group management?

What I'm really wondering is, instead of the proposal in GLEP27, if we
couldn't simply handle users like any other package. For example,
net-dns/djbdns needs,

  pkg_preinst() {
    # The nofiles group is no longer provided by baselayout.
    # Share it with qmail if possible.
    enewgroup nofiles 200

    enewuser dnscache -1 -1 -1 nofiles
    enewuser dnslog -1 -1 -1 nofiles
    enewuser tinydns -1 -1 -1 nofiles
  }

Instead of that, why couldn't we have something like,

  (R)DEPEND="sys-user/dnscache
             sys-user/dnslog
             sys-user/tinydns"

and then in each of those packages,

  (R)DEPEND="sys-group/nofiles"

That satisfies most of the requirements that *I* have for user and group
management on the system. Compared to the GLEP:

  * EUSERS + EGROUPS: replaced by (R)DEPEND.
  * Defining Accounts: anyone can add a new package already.
  * FEATURES=noautoaccts: use package.provided instead.
  * Local Overrides: use an overlay.
  * users-update: cleanup can be done with --depclean now.

You don't really have to care what UID/GID is assigned, because each
user/group will only be created once and referenced by name (as $PN). By
default, we could pick the first available UID in most packages.
I haven't thought much about the src_install implementation, but it
couldn't be *that* hard. Maybe install a $uid file to /var/lib/portage
somewhere to catch UID conflicts, and keep doing what user.eclass is
doing otherwise.

There isn't a ton of motivation in that GLEP, so I'm not sure what other
use cases I might have overlooked.

Reply via email to