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

[Chris Gianelloni]

On Wed, 2005-11-23 at 12:52 -0600, Brian Harring 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.
>
> You do this, and you'll break binpkgs that rely on it existing in
> eutils.  Yes it's annoying, but you _have_ to lead the functionality
> in eutils, duplicating it into whatever class you shove it into.

I had thought that this was resolved already in portage.

> That's the other side of the "can't remove eclasses" rule- can't yank
> functionality that is going to break installed ebuilds and binpkgs.

Fine.  I can simply make a new eclass and change the affected ebuilds.
I really don't have a problem with this.  The main reason for it is that
whatever eclass that enewuser is in really needs to DEPEND on shadow on
Linux.  Which brings up another point.  I see that a good number of
packages are calling enewuser in pkg_preinst.

These packages do not need shadow (though the system might, but that's
outside my scope) once they are installed, only to install.  However, it
is not needed to build.  What *DEPEND is correct?

> > I'd be willing to make all the changes to the tree to facilitate this,
> > and unless someone has a really good reason not to do so, I think I'll
> > probably do it after the Thanksgiving holiday.
>
> I'd delay this a bit personally, since it's a widespread change, and
> because people are probably going to be offline due to holiday cruft.

I was planning on taking care of it myself.  I was going to remove the
functions from eutils.eclass as my last step, but now I would simply
skip that step.  I would probably do something like add a warning to the
functions under eutils.eclass, too.

> Yah... you probably have the time to do it during the holiday stuff,
> but again, affecting a sizable collection of packages and requires
> ebuild devs to change the eclasses they're using.
>
> Plus the binpkg issue from above. ;)
> ~harring
-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux