| 1 |
On 15 Dec 2015 15:56, Ulrich Mueller wrote: |
| 2 |
> >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: |
| 3 |
> |
| 4 |
> > a flat text file akin to /etc/passwd is not readable. xml is readable. |
| 5 |
> |
| 6 |
> ESR's case study about the password file format seems to disagree: |
| 7 |
> http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332 |
| 8 |
|
| 9 |
because you cited it, i read it anyways. that document is about how text |
| 10 |
formats should be preferred over binary formats because they do not require |
| 11 |
custom tools to modify/update, and because it's easier for binary formats |
| 12 |
to screw themselves over from a portability/extensible pov. it does not |
| 13 |
champion the passwd format all by itself, and even says that it's a bit |
| 14 |
rigid, and you should consider tagged formats if you want something more. |
| 15 |
which we do. |
| 16 |
|
| 17 |
see also the example i posted to Alec as why the format is hostile to devs |
| 18 |
whereas my simple RST proposal has none of these issues. |
| 19 |
|
| 20 |
we also know the format works because it's been in use by CrOS for two |
| 21 |
years now, including: |
| 22 |
(1) profile stacking/overrides |
| 23 |
(2) marking users as "dead" |
| 24 |
(3) tools to verify/check consistency at rest |
| 25 |
(4) parallel installs |
| 26 |
(5) correct handling of ROOT and SYSROOT |
| 27 |
although 4/5 were written only with Linux/flat files in mind, so they do |
| 28 |
not support other OS's or account formats (e.g. ldap/etc...). i imagine |
| 29 |
we'll need to merge with the existing user.eclass logic rather than drop |
| 30 |
in replace. |
| 31 |
-mike |
Archives