| 1 |
>>>>> On Sat, 4 Apr 2015, Michał Górny wrote: |
| 2 |
|
| 3 |
>> This is not true for slotmoves. The previous slot can be reused by |
| 4 |
>> versions not matching the dependency spec of the move. One can even |
| 5 |
>> move some versions to a new slot, while leaving others in the old |
| 6 |
>> one. |
| 7 |
>> |
| 8 |
>> For example, you could have app-misc/foo-1:0 and app-misc/foo-2:0 |
| 9 |
>> and then do the following slotmove: |
| 10 |
>> |
| 11 |
>> slotmove =app-misc/foo-2* 0 2 |
| 12 |
>> |
| 13 |
>> How would your transparent conversion treat >=app-misc/foo-1:0 in a |
| 14 |
>> dependency? |
| 15 |
|
| 16 |
> As far as I'm concerned, this is a hack and as such it doesn't have to |
| 17 |
> cover all the possible cases. |
| 18 |
|
| 19 |
But in the worst case, your "hack" can cause a broken dependency |
| 20 |
graph. On the one hand, above mentioned >=app-misc/foo-1:0 matches |
| 21 |
all versions affected by the slotmove, so it should be converted. |
| 22 |
On the other hand, it is a perfectly valid dependency specification |
| 23 |
which could have been added after the slotmove, in which case it |
| 24 |
shouldn't be converted. You cannot know here what the intentions of |
| 25 |
the developer are. |
| 26 |
|
| 27 |
Ulrich |
Archives