Hi PETSc users and friends, I'm thinking to changing the versioned naming scheme used for PETSc packages in Debian. I'd like to hear if you think that might break something.
Up till now the minor version has been embedded in the package name, e.g. dev package is libpetsc3.6.2-dev, which strictly depends on the matching version of the library binary package. Previously the library package also included the minor version, e.g. libpetsc3.4.2. But the soname inside the library itself does not include the minor version. e.g. the current library file /usr/lib/x86_64-linux-gnu/libpetsc_real.so.3.6.2 has soname libpetsc_real.so.3.6 (I injected "_real" myself to distinguish from the version with complex number support). So all 3.6 versions should be binary compatible, whether 3.6.2 or 3.6.3, assuming upstream has correctly defined the soname. For this reason I removed the minor version from the library package name, so the package is just libpetsc3.6 not libpetsc3.6.2 or libpetsc3.6.3. But because of the tight dependence of the dev package, libpetsc3.6.2-dev needs libpetsc3.6 (3.6.2.dfsg1-3+b3), so libpetsc3.6 (3.6.3.dfsg1-1) won't do. Hence libpetsc3.6.2-dev cannot currently be installed parallel to libpetsc3.6.3-dev. For this reason, I think it might be simplest to just drop the minor version from the dev package. So then libdolfin-dev, for example, would depend on libpetsc3.6-dev instead of libpetsc3.6.2-dev. Now PETSc is installed using the minor version, e.g. separate directories /usr/lib/petscdir/3.6.2 and /usr/lib/petscdir/3.6.3. So in principle it is possible to organising the packages to allow parallel installations. But I'm not certain that anything is gained by having parallel installations for a library with the same soname. It could be done, e.g. libpetsc3.6-dev could be a virtual package that depends on the latest libpetsc3.6.x-dev. But would that provide any real benefit? It seems to me that using libpetsc3.6-dev as the dev package would be simpler. What do you think? Drew
