Re: [gentoo-dev] Use GLEP27!

[Alec Warner]

On Tue, Dec 15, 2015 at 6:19 AM, Mike Frysinger <vapier@g.o> wrote:

> On 15 Dec 2015 07:28, Ulrich Mueller wrote:
> > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> >
> > > On 14 Dec 2015 21:22, Ulrich Mueller wrote:
> > >> The spec seems incomplete. I cannot find a description of the user and
> > >> group files' format. (But in fact, there is a standard format which
> > >> suggests itself, namely that of the passwd(5) and group(5) files.)
> >
> > > i recall going with xml at the time, but i can't find reference to it.
> >
> > So the package manager would have to parse XML? We have tried to avoid
> > that, so far.
>
> not entirely accurate considering we have metadata.xml
>
> > >> Also having whole directory trees seems wasteful and doesn't fit so
> > >> well into the existing design of profiles. It might be simpler to put
> > >> "user" (or "passwd") and "group" files directly in the profile.
> > >> (If directories are really needed, we could use the scheme foreseen
> > >> in [1] for package.* and use.* files.)
> >
> > > we implemented this GLEP in Chromium OS and have been using it for a
> while:
> > >
> https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master
> >
> > > having a directory of files is way more user friendly imo and allows
> for
> > > a format that is easier to read.  /etc/passwd and /etc/group format are
> > > not that easy to scan and aren't portable.
> >
> > As we most likely will introduce profile file directories in EAPI 7
> > (see bug 282296), I'd rather use the same scheme for the user and
> > group files, but not something different.
>
> a flat text file akin to /etc/passwd is not readable.  xml is readable.
>

u trollin' bro?


>
> a markdown like format would work -- easy to parse by machines & humans
> and is a single stackable file.
> user:ntp
> <whitespace>uid:203
> <whitespace>gid:203
> user:man
> <whitespace>uid:13
> <whitespace>gid:13
> (using : as delimiter since that's what *NIX uses in /etc/passwd)
>
> the main one would grow probably to about 2000+ lines (~400 users in the
> tree and each entry takes ~4 lines assuming we enforce eliding of defaults)
> which isn't that terrible.  CrOS has a python script already for validating
> the db consistency.
>
> > >> Also a mechanism how a subprofile could undefine a user or group
> > >> defined in its parent seems to be missing.
> >
> > > what exactly do you mean by that ?  you want to make it so attempts to
> > > use the account yield an undefined error ?  or you want to have it so
> > > a child can revert back to an earlier definition ?
> >
> > The former.
>
> we already handle this in CrOS by explicitly including a flag in the file:
> defunct:true
>
> thus the PM need not care about the status when locating files or otherwise
> include any special handling.  if the last file you hit is marked as
> defunct,
> then enew{user,group} will throw an error when they're called.
> -mike
>