1 |
On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote: |
2 |
> Meanwhile, back to the "you want us to add what?", our dependency |
3 |
> graph *is* incomplete. |
4 |
|
5 |
so what ? i dont see it being a bug |
6 |
|
7 |
> Something like 600 ebuilds in the tree state a |
8 |
> dependency on gcc- we have 19000 ebuilds. Not all requires gcc to |
9 |
> build, but I'd bet it's a tad bit more then 600. |
10 |
|
11 |
and i continue to work day after day to make sure that 600 reaches 0 :p |
12 |
|
13 |
considering your system requires a virtual/libc in order to boot, tell me |
14 |
again why we must list it in every package which uses glibc ? |
15 |
|
16 |
> Full dependency information hasn't be viable due to resolver issues, |
17 |
> which will be fixed. |
18 |
|
19 |
so why dont you come back once you have something that is supposed to work ? |
20 |
you're proposing we start generating a ton of circular dependencies which we |
21 |
arent even close to handling now |
22 |
|
23 |
> Regarding the "require whatever is used to uncompress the source", |
24 |
> hadn't thought about it, but that _should_ be specified imo. That's |
25 |
> also being a bit anal, but frankly, if the resolver can handle it, why |
26 |
> shouldn't we specify the full deps? |
27 |
|
28 |
portage could be smart about it ... it can easily parse the contents of |
29 |
SRC_URI and put tar into whatever DEPEND rather than forcing a stupid policy |
30 |
of listing tar in thousands of ebuilds |
31 |
|
32 |
> To head off the "profile has it, so we don't need it", consider a |
33 |
> user profile, literally, a user desktop profile. Kde, gnome, office |
34 |
> crap, etc. Right now, for such a profile you would need the toolchain |
35 |
> tagged in, which I posit is invalid. |
36 |
|
37 |
considering if you try to `emerge` something while under said profile and you |
38 |
already removed binutils/gcc from the system, the emerge will fail ... the |
39 |
reason why is pretty obvious |
40 |
-mike |
41 |
-- |
42 |
gentoo-dev@g.o mailing list |