| 1 |
>>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: |
| 2 |
|
| 3 |
> On 15 Dec 2015 15:56, Ulrich Mueller wrote: |
| 4 |
>> ESR's case study about the password file format seems to disagree: |
| 5 |
>> http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332 |
| 6 |
|
| 7 |
> because you cited it, i read it anyways. that document is about how text |
| 8 |
> formats should be preferred over binary formats because they do not require |
| 9 |
> custom tools to modify/update, and because it's easier for binary formats |
| 10 |
> to screw themselves over from a portability/extensible pov. it does not |
| 11 |
> champion the passwd format all by itself, and even says that it's a bit |
| 12 |
> rigid, and you should consider tagged formats if you want something more. |
| 13 |
> which we do. |
| 14 |
|
| 15 |
> see also the example i posted to Alec as why the format is hostile to devs |
| 16 |
> whereas my simple RST proposal has none of these issues. |
| 17 |
|
| 18 |
Whatever the format will be, the more important question is where this |
| 19 |
would be implemented: |
| 20 |
|
| 21 |
- In the package manager, with user and group definition in profiles. |
| 22 |
This seems to be what GLEP 27 suggests, and as far as I can see, it |
| 23 |
would require an EAPI bump. Certainly doable, but last time we |
| 24 |
bumped profiles to a new EAPI we had a rather long transition |
| 25 |
period. |
| 26 |
|
| 27 |
- In user.eclass, which could be extended to use the EUSERS and |
| 28 |
EGROUPS variables defined in ebuilds. The problem is, where would |
| 29 |
one store the user and group definitions then? Profiles cannot be |
| 30 |
accessed from an eclass. |
| 31 |
|
| 32 |
Ulrich |
Archives