| 1 |
>>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: |
| 2 |
|
| 3 |
> On 15 Dec 2015 20:23, Anthony G. Basile wrote: |
| 4 |
>> > short/mid term, i was thinking of writing a new package that |
| 5 |
>> > holds the db and tools to query/manage it. user.eclass would |
| 6 |
>> > DEPEND on it and ask it for details, perhaps even doing the |
| 7 |
>> > actual fs updates (the bash code here is not pretty wrt locks and |
| 8 |
>> > python would be much nicer). that tool could even search |
| 9 |
>> > additional site paths (like /usr/local) to locate overrides. |
| 10 |
>> |
| 11 |
>> how do we get our own uid/gid's in there for our packages? just |
| 12 |
>> open a bug against the new package? |
| 13 |
|
| 14 |
> i would open the git repo to all devs and just let anyone push |
| 15 |
> directly and roll releases. maybe just push a tag and that's what |
| 16 |
> the ebuild would hit. no need to be gate keepers here since we don't |
| 17 |
> today w/ebuilds and calls to enew{user,group}. |
| 18 |
|
| 19 |
So if I want to add a new user or group, I would have to commit it to |
| 20 |
the repo of that package, then roll a new release, create an ebuild |
| 21 |
for that release, add that version to DEPEND of my own package's |
| 22 |
ebuild, and only then my ebuild could refer to the new user? And |
| 23 |
eventually, I'd have to take care of stabilising things, too? That |
| 24 |
looks like a cumbersome procedure, even if it is only intended as a |
| 25 |
stopgap solution until we can move things to a profile. |
| 26 |
|
| 27 |
Couldn't we add the user/group db to a subdir of the eclass dir |
| 28 |
instead, so that user.eclass could access it there? |
| 29 |
|
| 30 |
Ulrich |
Archives