1 |
On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote: |
2 |
> On Tue, Jun 14, 2011 at 8:54 AM, Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > The implicit system set dependency thing really, really needs to die; |
4 |
> > at the time of the rule, portage couldn't handle resolving graphs of |
5 |
> > that sort. ?PM resolvers for gentoo are generally a fair bit saner |
6 |
> > now thus doing what you're suggesting isn't really beneficial (frankly |
7 |
> > it causes some issues for stages, as zac noted). |
8 |
> |
9 |
> ++ |
10 |
> |
11 |
> It seems to me that the best policy would be for every package to just |
12 |
> list all its dependencies, and then users are free to run the default |
13 |
> experience that includes everything in @system, or a more trimmed-down |
14 |
> experience. |
15 |
|
16 |
An annoying, but valid complaint agains this is that the deps start |
17 |
getting heavy to maintain for developers, and aren't always viable to |
18 |
represent. Unpackers for example, are a pain in the ass for current |
19 |
EAPIs- that could be reduced in pain via addition of basic implicit |
20 |
deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2). |
21 |
|
22 |
Or devs could just be nudged into adding the appropriate DEPEND. |
23 |
repoman checking for it either way wouldn't be hard. |
24 |
|
25 |
The trickier point is gcc, but in my view, that's where we get the |
26 |
most gain- if the toolchain is represented in the deps it makes |
27 |
integrated cross compilation easier (keyword is integrated; crossdev |
28 |
already makes it reasonably straightforward I realize). |
29 |
|
30 |
|
31 |
> Plus, from time to time there is some debate about |
32 |
> removing some package from @system and the only way to figure out what |
33 |
> it breaks is a long discussion on -dev and lots of tinderbox testing, |
34 |
> and then lots of ebuilds being modified to add the dependency back in. |
35 |
> With explicit dependencies it is trivial to determine. |
36 |
|
37 |
It also improves -e behaviour; instead of the resolver being hardcoded |
38 |
to try promoting certain things (glibc and friends mainly), the |
39 |
resolver's normal logic can be used there. |
40 |
|
41 |
> And no, I don't think that Gentoo should fully support reduced-@system |
42 |
> builds, but there is no harm in making them more of a viable option. |
43 |
|
44 |
Personally... I think gentoo should aim for it actually. Question is |
45 |
how close we can get to it w/out overly burdening developers. |
46 |
|
47 |
Don't suppose someone has interest in looking into this? |
48 |
~brian |