Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

On Thu, 2005-11-24 at 19:34 +0000, Mike Frysinger wrote:
> On Thu, Nov 24, 2005 at 08:54:41AM -0500, Chris Gianelloni wrote:
> > On Thu, 2005-11-24 at 03:44 +0000, Mike Frysinger wrote:
> > > On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote:
> > > > OK.  I've been looking at some of these issues we've been having, and
> > > > I've been thinking of moving enewuser, egetent, and enewgroup to their
> > > > own eclass.  This will resolve some issues with things in system, or
> > > > otherwise early on, requiring shadow on Linux to get useradd.  Two
> > > > examples of this are bug #113298 and bug #94745.  By putting them in
> > > > their own eclass, we can keep from adding shadow to DEPEND in eutils,
> > > > while still putting the dependency in the eclass that uses it.
> > >
> > > i think i suggested this somewhere before, but why dont we just add
> > > shadow to packages.build ... then it'll be in stage[123] and the DEPEND
> > > will be a moot point
> >
> > That doesn't solve the issue.
>
> of course it does ... putting a package in packages.build means it will
> be in all stages which means no package (like cronbase) will ever fail
> again because the useradd binaries will always exist

I'm looking to minimize what is in a stage1 tarball, not increase it.  I
would much prefer that we instead had a proper dependency tree, than
hacking around it.  Applications that need to add users on Linux
*should* DEPEND on shadow.  They should not rely on it being already
present.  Plus, your solution does not work retroactively to repair
issues with the 2005.0, 2005.1, or 2005.1-r1 stages, while mine does.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux