On Fri, Jul 01, 2005 at 02:30:12PM -0400, Mike Frysinger wrote: > 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
I do. :) We do a lot of work to have deps accurate, ignoring a fairly critical class of dependencies cause it's extra work seems a bit short sighted. Beyond that, see the user profile bit below, it shades incomplete toolchain dependencies as 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 Floating the idea. BDEPEND implementation (if people thought it was a good idea) would go alongside use/slot dep implementation. The short version is BDEPEND is fairly heavily related to domain work for collapsing config/ROOT into a single groupping portage can work with. No BDEPEND means that things are nastier for dealing with x-compile from portage's standpoint, so a general yay/nay on the concept is needed (hence it being raised 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 Dep should be represented imo, regardless if portage automatically handles it (as mentioned above) or manually tacked in. Automatic tagging of such a dep makes a helluva lot more sense then manual. > > 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 Err... missing the point, and proving my point. Current portage _will_ fail because it's an unstated dependency. Why shouldn't portage be provided the deps it needs so it can figure out what is needed to get to what the user requested? ~harring
pgprEbffLvZOL.pgp
Description: PGP signature
