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. > 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. - 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. - What we need is that ebuilds build against KDE slot X force a rebuild of those dependencies, which were against KDE slot Y as well as every other installed ebuild depending on them. Right now my fugly slot_rebuild() workaround lets the user do the job by hand. 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? :[]<>? Wouldn't it be better to have a extensible scheme, like e.g. $category/$ebuild[use:foo,!bar;slot:x,y] ? Carsten
pgpu4QYUzO1bD.pgp
Description: PGP signature
