Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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