On 17 Dec 2015 11:57, Ulrich Mueller wrote:
> >>>>> 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.yes, that's what you'd have to do. considering packages themselves have to go through stabilization, that particular aspect isn't a big deal. or we just auto-stable it. > Couldn't we add the user/group db to a subdir of the eclass dir > instead, so that user.eclass could access it there? people get whiny when we leverage eclass/ for storage. but we do it already, so it makes no difference to me. -mike
signature.asc
Description: Digital signature
