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