| 1 |
On Mon, Dec 26, 2005 at 09:09:31PM +0100, Carsten Lohrke wrote: |
| 2 |
> On Saturday 24 December 2005 02:04, Brian Harring wrote: |
| 3 |
> > dev-lang/python[tcltk] |
| 4 |
> > ^^^ need that atom resolved with use flag tcltk enabled |
| 5 |
> |
| 6 |
> I think that's exactly what someone told me months ago. :) |
| 7 |
> |
| 8 |
> > >=sys-apps/portage-2.0[sandbox,!build] |
| 9 |
> > |
| 10 |
> > ^^^ need >=portage-2.0 merged with sandbox on, build off. |
| 11 |
> |
| 12 |
> I wonder if portage deals fine with subtle dependency incompatibilities, when |
| 13 |
> one package has foo[!bar] and another one foo[bar] as dependency and spits |
| 14 |
> out a reasonable error message to apply mutual blockers. |
| 15 |
|
| 16 |
Actually, you just hit upon one of the main reasons use/slot deps |
| 17 |
have taken so damn long. |
| 18 |
|
| 19 |
Jason can state it better, but our resolver basically chooses a single |
| 20 |
path when doing the resolution; if that resolution turns out to be an |
| 21 |
issue during later resolution steps, existing resolver doesn't back |
| 22 |
track and choose a different (valid) path. |
| 23 |
|
| 24 |
Note the up/down cycling bugs. Guess how that comes about? |
| 25 |
|
| 26 |
use/slot deps is a combination of depset extension (plus any code that |
| 27 |
deals with depset), and resolver extension so it handles the extension |
| 28 |
of depset properly- namely, getting issues from above handled, trying |
| 29 |
to dig it's way out of use cycles that aren't hard deps, etc. |
| 30 |
|
| 31 |
So... basically, your concern is with the resolver, not use/slot deps |
| 32 |
syntax. |
| 33 |
|
| 34 |
|
| 35 |
> > kde-libs/kde:3 |
| 36 |
> > ^^^ need any kde, with slotting enabled. |
| 37 |
> > |
| 38 |
> > kde-libs/kde:3,4 |
| 39 |
> > ^^^ need any kde, slotting 3 or 4. |
| 40 |
> > |
| 41 |
> > Combination? Not set in stone afaik, the implementation I have |
| 42 |
> > sitting in saviour doesn't care about the ordering however. |
| 43 |
> |
| 44 |
> This is the one I'm entirely not sure what it is good for. To me it looks more |
| 45 |
> like a workaround for missing dependency ranges, but it won't solve any issue |
| 46 |
> for KDE related packages. |
| 47 |
|
| 48 |
What are dep ranges? It's the intersection of any version set's |
| 49 |
specified by common cat/pkgs. In other words, instead of just |
| 50 |
processing atom by atom, grab the depends, collapse them down into |
| 51 |
cp->version restrictions, _then_ do the search. The issue you're |
| 52 |
pointing at isn't use/slot dep based, it's resolver based (again). ;) |
| 53 |
|
| 54 |
|
| 55 |
> - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 is |
| 56 |
> due, we can change to =kde-libs/kde-3.5* because everything else won't be |
| 57 |
> supported anymore. So unless I miss something, kde-libs/kde:X is superfluous. |
| 58 |
|
| 59 |
Missing something /me thinks. |
| 60 |
shouldn't really be specifying >=kde-x.y; should be specifying the |
| 61 |
slotting. Do that, and you wouldn't have to go back and change it |
| 62 |
over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a |
| 63 |
different slot. |
| 64 |
|
| 65 |
Basically... it's how it *should* be done from the get go, rather then |
| 66 |
going back and fixing things via tweaking the scary eclass y'all have. :) |
| 67 |
|
| 68 |
|
| 69 |
> As a general remark I'd like to know if and how this enhanced dependency |
| 70 |
> syntax is ordered. :[], []: or is both allowed!? What if we find out, that we |
| 71 |
> need to consider another factor, later? :[]<>? |
| 72 |
|
| 73 |
Like I stated in a previous email, the ordering isn't specified- right |
| 74 |
now we can split upon [] matches to handle it regardless of ordering, |
| 75 |
although I'd think some form of ordering would be wise... |
| 76 |
|
| 77 |
~harring |
Archives