Re: petsc packages: drop the minor version in package names?

[Johannes Ring <johannr@simula.no>]

On Tue, Mar 15, 2016 at 11:14 AM, Drew Parsons <dparsons@debian.org> wrote:
> 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?

Sounds good to me.

Johannes