On Fri, 2005-11-25 at 19:24 +0000, Mike Frysinger wrote: > > 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
Well, apparently with shadow in packages.build we can no longer build a stage1 tarball from a stage3. We also cannot bootstrap, as both of these tasks strip a large number of USE flags. As soon as I removed shadow from packages.build, my builds resumed working. > i wouldnt qualify shadow as a part of a proper dependency tree since > it's the ebuild itself that requires it, not the package It is required by our ebuild to build the package. I'd call that a dependency. If you want to call it a dependency of the eclass or portage or whatever, I don't care. It is still a dependency in the dependency tree. > > 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 That still will not fix the issue. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
