On 15 Dec 2015 20:23, Anthony G. Basile wrote:
> On 12/15/15 4:55 PM, Mike Frysinger wrote:
> > On 15 Dec 2015 22:35, Ulrich Mueller wrote:
> >> Whatever the format will be, the more important question is where this
> >> would be implemented:
> >>
> >> - In the package manager, with user and group definition in profiles.
> >>   This seems to be what GLEP 27 suggests, and as far as I can see, it
> >>   would require an EAPI bump. Certainly doable, but last time we
> >>   bumped profiles to a new EAPI we had a rather long transition
> >>   period.
> >>
> >> - In user.eclass, which could be extended to use the EUSERS and
> >>   EGROUPS variables defined in ebuilds. The problem is, where would
> >>   one store the user and group definitions then? Profiles cannot be
> >>   accessed from an eclass.
> >
> > long term, i think profiles are better to hold the db as it provides for
> > clean stacking and is trivial for site-specific extension/control, as well
> > as image builders via something like catalyst.
> >
> > short/mid term, i was thinking of writing a new package that holds the db
> > and tools to query/manage it.  user.eclass would DEPEND on it and ask it
> > for details, perhaps even doing the actual fs updates (the bash code here
> > is not pretty wrt locks and python would be much nicer).  that tool could
> > even search additional site paths (like /usr/local) to locate overrides.
> 
> how do we get our own uid/gid's in there for our packages?  just open a
> bug against the new package?

i would open the git repo to all devs and just let anyone push directly
and roll releases.  maybe just push a tag and that's what the ebuild would
hit.  no need to be gate keepers here since we don't today w/ebuilds and
calls to enew{user,group}.

the question is how to handle the tools.  i'm thinking we should have two
distinct packages so the db could be completely overridden by overlays.

the tools could be in the same repo or a sep one.  i don't feel strongly
either way as we'd just mark base-system@ as the maintaining herd.
-mike

Attachment: signature.asc
Description: Digital signature

Reply via email to