On Fri, 2005-12-30 at 22:54 +0900, Jason Stubbs wrote: > > > A still inelegant solution, but one that I could live with, is to > leave SLOT handling as it is now and to take Brian's syntax of > key:slot,slot using it specifically for the case where a set of > ebuilds must all use the same slot. > > Hence, rather than digikam and friends having "|| ( kdelibs:3.4 > kdelibs:3.5 )" each would have just "kdelibs:3.4,3.5". It still sounds > messy given the current redesign of atom handling, but it would seem > to offer a better chance of not being bug-ridden...
Hmm.. Do you mean this -after- expansion, or as hard-coded into the tree of ebuilds? If so, it's probably a no-go. Since the dep as stated in the tree doesn't even -want- to bind itself to a SLOT (can work with any 3.x version, is probably the most common criteria). And, I'm not sure just how this mangling would look when expanded in the installed package database, can you elaborate a bit? //Spider -- begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end
signature.asc
Description: This is a digitally signed message part