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. 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
signature.asc
Description: Digital signature
