On Fri, Nov 25, 2005 at 09:24:44AM -0500, Chris Gianelloni wrote: > 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.
and when we move the user management hacks out of eclasses and into portage itself, where do you think shadow will end up ? in stage1 is my guess i wouldnt qualify shadow as a part of a proper dependency tree since it's the ebuild itself that requires it, not the package > Plus, your solution does not work retroactively to repair > issues with the 2005.0, 2005.1, or 2005.1-r1 stages, while mine does. tell users to stop using stage[12], you're already going that route :p -mike -- gentoo-dev@gentoo.org mailing list
