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