* Roland Stigge (stigge@debian.org) wrote: > adopting the jasper JPEG 2000 library[1] in Debian, I'm struggling with > the upstream convention of incorporating the package version into the > library name. I.e., the shared library is created as > > /usr/lib/libjasper-1.701.so.1.0.0 > > for jasper-1.701.0. Following Policy chapter 8, the respective binary > package names would be: > > libjasper-1.701-1 > libjasper-1.701-dev > > This implies that on every upstream update, the binary package name > would need to be changed. > > -> Is this the way to go or should I try to convince upstream to change > the policy and name the shared object e.g. /usr/lib/libjasper.so.1.0.0 > utilizing the soversion on updates? Try to convince upstream to change to something appropriate for a stable library. If it's not a stable library, don't put it in Debian. The libjasper1-1 (or whatever) package should be based on the ABI (which is what the soname change is supposted to indicate a change in). The libjasper-dev package should be based on the API. If you expect the API to change in a non-backwards-compatible way then you may need to add a version number to the libjasper-dev package name. Usually this only happens 'major' release numbers amoung libraries (though not always, of course, so check with your upstream as to what their policy is). > -> Besides, the -dev package includes include files in > /usr/include/jasper/ (e.g. /usr/include/jasper/jasper.h) which causes > the respective -dev packages of different upstream versions to conflict > anyway. Would I have to provide a virtual package (e.g. libjasper-dev) > to conflict with? If the API changes in a way that is not backwards-compatible then hopefully upstream themselves would adopt a new directory (such as /usr/include/jasper2/) or some such, in which case you'd be able to have libjasper-dev (the original) and libjasper2-dev (new major version, new API, *not* related to the ABI or SONAME) installed at the same time. They'd each depend on their associated libjasper*-1 as well, which means that those would need to be co-installable too. For a new major upstream version the library name would probably change too though, so that the .so symlink wouldn't be a problem. Stephen
Attachment:
signature.asc
Description: Digital signature