[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: jpeg8 vs jpeg-turbo



Vincent Bernat <bernat@debian.org> writes:
>  ❦ 24 avril 2013 13:08 CEST, Ondřej Surý <ondrej@sury.org> :

>> We have a plenty of libraries (and other packages) who do conflict
>> between themselves, so we know the drill.
>>
>> Also Debian no longer ships libjpeg62, so there's not conflict there
>> at least for baseline implementation (libjpeg62 API/ABI). Remember we
>> are speaking about wheezy+1 now.
>>
>> For libjpeg8-turbo you can just declare Conflict with libjpeg8 and it
>> will be used just in the applications who explicitly link with
>> libjpeg-turbo-dev.

> Which means that some applications won't be coinstallable?

For this to be viable, you'd need to do the same thing that we do for MIT
Kerberos and Heimdal, namely:

* Create conflicting -dev packages.
  - For special bonus points, have both conflicting and co-installable
    ones, as with the -multidev Kerberos packages.
* Give the libraries different SONAMEs.
* Ensure both libraries use symbol versioning with different versions.
* Ensure the shared library packages are coinstallable.

Note that you will still lose if you run into a situation where some piece
JPEG library data has to be shared between two other shared libraries, one
of which uses one library and one of which uses the other.  I don't know
if we have such a situation.  (There are some edge cases like that with
the Kerberos libraries; for example, it's possible to use libremctl from
inside an application linked with Heimdal, but you get a link-time warning
and MEMORY ticket caches don't work because the two libraries use
independent data structures.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: