Re: [gentoo-dev] splitting build deps out from depends

[Mike Frysinger <vapier@gentoo.org>]

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