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
signature.asc
Description: This is a digitally signed message part
