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