Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
Date: Wed, 30 Nov 2005 14:57:04
Message-Id: 1133362287.5990.16.camel@cgianelloni.nuvox.net
In Reply to: Re: [gentoo-dev] enewuser/enewgroup getting their own eclass by Mike Frysinger
1 On Fri, 2005-11-25 at 19:24 +0000, Mike Frysinger wrote:
2 > > I'm looking to minimize what is in a stage1 tarball, not increase it. I
3 > > would much prefer that we instead had a proper dependency tree, than
4 > > hacking around it. Applications that need to add users on Linux
5 > > *should* DEPEND on shadow. They should not rely on it being already
6 > > present.
7 >
8 > and when we move the user management hacks out of eclasses and into
9 > portage itself, where do you think shadow will end up ? in stage1 is
10 > my guess
11
12 Well, apparently with shadow in packages.build we can no longer build a
13 stage1 tarball from a stage3. We also cannot bootstrap, as both of
14 these tasks strip a large number of USE flags. As soon as I removed
15 shadow from packages.build, my builds resumed working.
16
17 > i wouldnt qualify shadow as a part of a proper dependency tree since
18 > it's the ebuild itself that requires it, not the package
19
20 It is required by our ebuild to build the package. I'd call that a
21 dependency. If you want to call it a dependency of the eclass or
22 portage or whatever, I don't care. It is still a dependency in the
23 dependency tree.
24
25 > > Plus, your solution does not work retroactively to repair
26 > > issues with the 2005.0, 2005.1, or 2005.1-r1 stages, while mine does.
27 >
28 > tell users to stop using stage[12], you're already going that route :p
29
30 That still will not fix the issue.
31
32 --
33 Chris Gianelloni
34 Release Engineering - Strategic Lead
35 x86 Architecture Team
36 Games - Developer
37 Gentoo Linux

Attachments

File name MIME type
signature.asc application/pgp-signature