1 |
On Wed, Nov 30, 2011 at 11:34 AM, Zac Medico <zmedico@g.o> wrote: |
2 |
> Ignoring circular dependencies doesn't make them go away. Ignoring |
3 |
> dependencies can lead to build failures that could have been avoided if |
4 |
> they were expressed in a way that the dependency resolver could properly |
5 |
> account for them. |
6 |
|
7 |
++ |
8 |
|
9 |
One man's gawk is another man's KDE. A solution that expresses all |
10 |
dependencies and handles them well is much more elegant than one that |
11 |
requires hard-coding a list of core dependencies that we just think |
12 |
are too complicated to work out. |
13 |
|
14 |
Of course, to really get to the point where we'd have no system set at |
15 |
all we'd need to somehow automate the dependency generation, since |
16 |
otherwise ebuild maintenance would be very painful. Considering that |
17 |
we can't even tell if a program will halt it is clearly impossible to |
18 |
guarantee a perfect set of runtime dependencies. Of course, you might |
19 |
be able to come up with something that is good enough - especially |
20 |
when combined with the ability to add them in manually. |
21 |
|
22 |
None of this completely solves the fundamental bootstrapping problem. |
23 |
However, a full set of dependency specifications would let you at |
24 |
least determine what the minimal bootstrap actually is. |
25 |
|
26 |
I see all of this as more of an aspirational goal - one that we |
27 |
shouldn't fret about not being able to achieve, or subject ourselves |
28 |
to tremendous pain to get a little closer to. However, we also |
29 |
shouldn't hold back when opportunities to take a step closer arise. |
30 |
|
31 |
Rich |