| 1 |
On Mon, Aug 5, 2013 at 12:15 PM, Alexis Ballier <aballier@g.o> wrote: |
| 2 |
> On Mon, 5 Aug 2013 18:10:46 +0200 |
| 3 |
> Michał Górny <mgorny@g.o> wrote: |
| 4 |
>> We can simply have multiple virtual versions, each depending |
| 5 |
>> on the proper jpeg & jpeg-turbo versions. |
| 6 |
> |
| 7 |
> you can do it that way, yes. |
| 8 |
> |
| 9 |
> what will you do when jpeg 10 is out or when libjpeg-turbo changes its |
| 10 |
> abi ? wait for each provider to have a release that changes the abi ? |
| 11 |
> this doesnt sound sane |
| 12 |
|
| 13 |
I think a thorough solution needs to handle the passthrough situation, |
| 14 |
and ideally the multiple libs per package situation. |
| 15 |
|
| 16 |
Our whole versioning system wasn't really set up with this stuff in |
| 17 |
mind either. We're dealing with ABI/SONAME versions here - not |
| 18 |
functionality versions. A package with jpeg-turbo SONAME 0.6 might be |
| 19 |
a superset of all the functionality in SONAME 0.9 - the larger number |
| 20 |
doesn't mean better, just different. |
| 21 |
|
| 22 |
It might still be possible to handle this with subslots as they are |
| 23 |
currently implemented, but I'd have to really mess around with it to |
| 24 |
be sure. The logic of higher-number = more-desirable is likely to |
| 25 |
cause problems - you don't want your system to force you to move from |
| 26 |
jpeg-turbo to jpeg because only the latter is a dep of a newer |
| 27 |
virtual. |
| 28 |
|
| 29 |
Rich |
Archives