On Fri, Jul 01, 2005 at 08:16:46PM -0500, Kito wrote: > Accurate deps should be a goal for the tree, a long term one > obviously... Picking at the words (not you), but "long term" == it gets ignored till someone starts screaming/foaming at the mouth.
If BDEPEND were added, it's extra data that next version of portage could use to do crazy stuff, and it wouldn't screw up existing portage in anyway. What crazy stuff? Aside from having _full_ deps so we can trust portage not to do something stupid if the profile is missing, BDEPEND provides classification of a set of atoms that must be native to a system. Since there is a seperation of what is effectively chost (bdepend) and ctarget (depend), you're giving portage a classification of depends for a package that it can use to do (what I'm calling) interdomain deps. In other words for an arm x-compile target's BDEPENDs can be mapped back to the native host of the box. It allows the possibility for portage to natively support x-compile. Without it, it's not possible natively in portage, nor is the solution totally clean (imo at least). So... getting back to the long term bit, input in the here and now as to why this will never be implemented is required. Just to point out a bit again, the metapkg proposal will allow grouping of arbitrary atoms, so a virtual/c-toolchain could be used to collapse binutils/glibc/etc down to a single atom (indirection rocks, no? :) ~harring
pgpTy0CoPZAVT.pgp
Description: PGP signature
