[Debichem-devel] VOTCA available on my PPA

[Michael Banck]

Hi,

sorry it took so long, but I finally had another look at VOTCA.

On Mon, Dec 23, 2013 at 03:12:44PM -0700, Christoph Junghans wrote:
> 2013/12/23 Michael Banck <mbanck at debian.org>:
> > On Mon, Dec 23, 2013 at 08:38:27AM -0700, Christoph Junghans wrote:
> >> 2013/12/22 Michael Banck <mbanck at debian.org>:
> >> > On Sun, Oct 27, 2013 at 02:55:04PM -0600, Christoph Junghans wrote:
> >> >> I finalize found the time to make the first steps to package VOTCA for Debian.
> >> >> The source/binary builds are available on
> >> >> <https://launchpad.net/~ottxor/+archive/votca>.
> >> >>
> >> >> Please have a look and help me to improve it, so that I can hand it
> >> >> over to debichem soon.
> >> >
> >> > I took a look at votca-tools now (as this is a Build-Depends for
> >> > votca-csg and has to be uploaded first).  I see the following issues:
> >> >
> >> > 1. The -dev package is named libvotca-tools2-dev, i.e. includes the
> >> > soversion.  This is discouraged (but unfortunately the library
> >> > maintainer's guide advocated it at least last time I looked), unless a
> >> > project is very widely used and switching all programs using it
> >> > immediately is not feasable (like for GTK1->GTK2, oder Qt4->Qt5). I
> >> > understand that Ubuntu ships it, but I would rather rename it to
> >> > libvotca-tools-dev and either let Ubuntu deal with it, or add
> >> > compatibility Replaces/Conflicts/Provides for it.
> >>
> >> Renaming is fine as it has only been released as PPA.
> >> So should we just rename the dev package or both?
> >
> > Only the -dev package, the runtime library is required to carry the
> > soversion in the package name.
>
> Done.
 
You renamed it to votca-tools-dev and dropped the 'lib'.  This is not
necessary, the development library should have the same name as the
runtime library, just the soversion be replaced with -dev.  So it'd be
libvotca-tools-dev.  The actual library is libvotca_tools.so, but I
think replacing the underscore with a dash is correct (the underscore is
an illegal package name character).

The other thing which I only stumbled upon now is the soversion itself.
Apparently it is getting calculated at compile-time from the project
version (currently 1.2.3) by taking the seconf number (2).  Is there
some rationale for this?  Usually the best practise is to decouple
library and package versioning, as the library versioning must increase
when an incompatible API change occurs.  If the API is only added to,
the second digit (which you are not using) should be incremented.

Note that increasing the soversion implies changing the package name in
Debian and thus rebuilding all reverse dependencies (well, in your case
only votca-csg so far I guess).  

Maybe you are carefully changing your project_version according to this,
but usually project rev their major version when they break backwards
compatibility, so I am raising this here.  My apologies if you already
knew all this.


Michael