> > > 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). Addendum to this; no cycles are induced, cause portage (current versions) don't know about BDEPEND, and won't know about bdepend until a resolver is in place that can handle it.
So... forget about pissing off current portage, this is looking forward a bit. ~harring
pgptZE5RiHZMj.pgp
Description: PGP signature
