On Fri, 2005-07-01 at 13:42 -0500, Brian D. Harring wrote: > 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. :) >
I don't as well, until you can prove that portage can handle a system install without a system profile, and everything depending on the system profile. Just an example what an 'innocent' fix can do by adding a system profile item somewhere into an DEPEND where it does not belong, see bug #96209. > 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). > Like every other idea, it might be nice - just as the multi-slot-per-version idea would have been cool for x-compiling ... but still are not implemented. Do not get me wrong .. I assume this will do wonders for x-compiling and prevent world war, etc, but as Linus (or some other guy) would say: Show me the Code. On another note .. how do you guys plan to handle this BDEPEND .. just for x-compile, or global? If global, any ideas how to solve the circular issues ??? > > > > 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. > True, but its not always viable .. how much longer will it take portage to compute a dep graph that is 200 times more complete? 2 times? 10? Also as already asked, what about the chicken egg issue ... (think tar needing tar, or gzip needing gzip to unpack)? > > > 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? > I do not think so .. his point is: htf do you build binutils without binutils installed ? Same for gcc. Thanks, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa
signature.asc
Description: This is a digitally signed message part
