On Fri, Jul 01, 2005 at 08:53:18PM +0200, Diego 'Flameeyes' Pettenò wrote: > On Friday 01 July 2005 20:42, Brian D. Harring wrote: > > 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? > BDEPEND is not going to resolve the case Mike shown. > > GCC bdepends over GCC to compile, you don't have GCC, you can't install GCC, > you can't install anything (a part from binpkgs). > But if you put GCC in profile, no need to depend on it, you'll always have > one > also if nothign depends on it and the problem is resolved. > > BTW, as I already stated on irc, GCC is a RDEPEND not a BDEPENED because of > libgcc_s.so and libstdc++.so, so... Bleh, aparently I missed the point of his example- the depclean bit would apply for yanking packages that aren't needed, make and friends for example.
Holding onto unwind/stdc++/gcc_s (gcc[-nocxx]) is another beast, which still not sure about addressing aside from the hated RDEPEND=virtual/libc. Addressing earler question of why virtual/libc should actually be rdep'ed (and mike's example), figure it thus, the only thing that's keeping portage from wiping it on a depclean run is that it's in the profile. Corrupt your profile, portage _will_ wipe it because the depgraph isn't complete. The response to that I'm sure is "well don't corrupt your profile", but one thing to note is that it implicitly forces requiring a valid profile. Thing is, you're forcing the requirement of the profile, and that it specify information that keeps portage from doing stupid things. There's no valid reason that portage management of a system must rely on the profile as a crutch to keep it from doing stupid things, when specifying *full* dependencies removes teh crutch, and gives portage the knowledge it needs to do other crazy crap that is desirable. ~harring
pgpl35qT3eYRK.pgp
Description: PGP signature
