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