public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alec Warner <antarus@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Use GLEP27!
Date: Tue, 15 Dec 2015 10:35:59 -0800	[thread overview]
Message-ID: <CAAr7Pr_sWwFXWXKBhszrBXF=Dw6_2pnMAGivTLQQHy-3toDzmA@mail.gmail.com> (raw)
In-Reply-To: <20151215141936.GQ11489@vapier.lan>

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

On Tue, Dec 15, 2015 at 6:19 AM, Mike Frysinger <vapier@gentoo.org> 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
>

[-- Attachment #2: Type: text/html, Size: 4141 bytes --]

  parent reply	other threads:[~2015-12-15 18:36 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-13 18:03 [gentoo-dev] Determenistic system group and user id Alexey Shvetsov
2015-12-13 20:41 ` [gentoo-dev] Use GLEP27! Robin H. Johnson
2015-12-14  4:49   ` Alexey Shvetsov
2015-12-14  6:06     ` Robin H. Johnson
2015-12-14 14:48       ` Doug Goldstein
2015-12-14  9:22   ` Michał Górny
2015-12-14 14:57     ` Doug Goldstein
2015-12-14 20:22     ` Ulrich Mueller
2015-12-15  4:00       ` Peter Stuge
2015-12-15  5:13       ` Mike Frysinger
2015-12-15  6:28         ` Ulrich Mueller
2015-12-15 14:19           ` Mike Frysinger
2015-12-15 14:33             ` Michał Górny
2015-12-15 15:08               ` Mike Frysinger
2015-12-15 15:24                 ` Anthony G. Basile
2015-12-15 19:17                   ` Mike Frysinger
2015-12-15 14:56             ` Ulrich Mueller
2015-12-15 15:00               ` Michał Górny
2015-12-15 15:10                 ` Mike Frysinger
2015-12-15 15:16               ` Mike Frysinger
2015-12-15 20:52               ` Mike Frysinger
2015-12-15 21:35                 ` Ulrich Mueller
2015-12-15 21:55                   ` Mike Frysinger
2015-12-16  1:23                     ` Anthony G. Basile
2015-12-16  4:04                       ` Mike Frysinger
2015-12-17 10:57                         ` Ulrich Mueller
2015-12-17 13:45                           ` Mike Frysinger
2015-12-15 18:35             ` Alec Warner [this message]
2015-12-15 19:22               ` Mike Frysinger
2015-12-13 20:58 ` [gentoo-dev] Determenistic system group and user id Mike Gilbert
2015-12-13 22:23 ` Alec Warner
2015-12-13 23:46   ` Marc Schiffbauer
2015-12-14  5:17   ` Alexey Shvetsov
2015-12-14  6:39   ` Robin H. Johnson
2015-12-14 20:03     ` Alec Warner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAr7Pr_sWwFXWXKBhszrBXF=Dw6_2pnMAGivTLQQHy-3toDzmA@mail.gmail.com' \
    --to=antarus@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox