| 1 |
> > > Full dependency information hasn't be viable due to resolver issues, |
| 2 |
> > > which will be fixed. |
| 3 |
> > |
| 4 |
> > so why dont you come back once you have something that is supposed to work ? |
| 5 |
> > you're proposing we start generating a ton of circular dependencies which we |
| 6 |
> > arent even close to handling now |
| 7 |
> |
| 8 |
> Floating the idea. BDEPEND implementation (if people thought it was a |
| 9 |
> good idea) would go alongside use/slot dep implementation. |
| 10 |
> |
| 11 |
> The short version is BDEPEND is fairly heavily related to domain work |
| 12 |
> for collapsing config/ROOT into a single groupping portage can work |
| 13 |
> with. |
| 14 |
> |
| 15 |
> No BDEPEND means that things are nastier for dealing with x-compile |
| 16 |
> from portage's standpoint, so a general yay/nay on the concept is |
| 17 |
> needed (hence it being raised now). |
| 18 |
Addendum to this; no cycles are induced, cause portage (current |
| 19 |
versions) don't know about BDEPEND, and won't know about bdepend until |
| 20 |
a resolver is in place that can handle it. |
| 21 |
|
| 22 |
So... forget about pissing off current portage, this is looking |
| 23 |
forward a bit. |
| 24 |
~harring |
Archives