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