1 |
On 15 Dec 2015 07:28, Ulrich Mueller wrote: |
2 |
> >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: |
3 |
> |
4 |
> > On 14 Dec 2015 21:22, Ulrich Mueller wrote: |
5 |
> >> The spec seems incomplete. I cannot find a description of the user and |
6 |
> >> group files' format. (But in fact, there is a standard format which |
7 |
> >> suggests itself, namely that of the passwd(5) and group(5) files.) |
8 |
> |
9 |
> > i recall going with xml at the time, but i can't find reference to it. |
10 |
> |
11 |
> So the package manager would have to parse XML? We have tried to avoid |
12 |
> that, so far. |
13 |
|
14 |
not entirely accurate considering we have metadata.xml |
15 |
|
16 |
> >> Also having whole directory trees seems wasteful and doesn't fit so |
17 |
> >> well into the existing design of profiles. It might be simpler to put |
18 |
> >> "user" (or "passwd") and "group" files directly in the profile. |
19 |
> >> (If directories are really needed, we could use the scheme foreseen |
20 |
> >> in [1] for package.* and use.* files.) |
21 |
> |
22 |
> > we implemented this GLEP in Chromium OS and have been using it for a while: |
23 |
> > https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master |
24 |
> |
25 |
> > having a directory of files is way more user friendly imo and allows for |
26 |
> > a format that is easier to read. /etc/passwd and /etc/group format are |
27 |
> > not that easy to scan and aren't portable. |
28 |
> |
29 |
> As we most likely will introduce profile file directories in EAPI 7 |
30 |
> (see bug 282296), I'd rather use the same scheme for the user and |
31 |
> group files, but not something different. |
32 |
|
33 |
a flat text file akin to /etc/passwd is not readable. xml is readable. |
34 |
|
35 |
a markdown like format would work -- easy to parse by machines & humans |
36 |
and is a single stackable file. |
37 |
user:ntp |
38 |
<whitespace>uid:203 |
39 |
<whitespace>gid:203 |
40 |
user:man |
41 |
<whitespace>uid:13 |
42 |
<whitespace>gid:13 |
43 |
(using : as delimiter since that's what *NIX uses in /etc/passwd) |
44 |
|
45 |
the main one would grow probably to about 2000+ lines (~400 users in the |
46 |
tree and each entry takes ~4 lines assuming we enforce eliding of defaults) |
47 |
which isn't that terrible. CrOS has a python script already for validating |
48 |
the db consistency. |
49 |
|
50 |
> >> Also a mechanism how a subprofile could undefine a user or group |
51 |
> >> defined in its parent seems to be missing. |
52 |
> |
53 |
> > what exactly do you mean by that ? you want to make it so attempts to |
54 |
> > use the account yield an undefined error ? or you want to have it so |
55 |
> > a child can revert back to an earlier definition ? |
56 |
> |
57 |
> The former. |
58 |
|
59 |
we already handle this in CrOS by explicitly including a flag in the file: |
60 |
defunct:true |
61 |
|
62 |
thus the PM need not care about the status when locating files or otherwise |
63 |
include any special handling. if the last file you hit is marked as defunct, |
64 |
then enew{user,group} will throw an error when they're called. |
65 |
-mike |