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 |