[Debian-science-sagemath] Package cryptominisat, an optional dependency of SageMath

[Ximin Luo]

Julian Rüth:
> Hi Ximin,
> 
> thanks for having a look.
> 
> * Ximin Luo <infinity0 at debian.org> [2018-08-11 06:50:00 +0000]:
>> Did you have a specific reason for choosing the library package naming
>> scheme libcryptominisat5-5.6 and libcryptominisat5-5.6-dev? Common
>> Debian convention would be to call the packages lib${NAME}${SOVERSION}
>> and lib${NAME}-dev, so it would normally be libcryptominisat5.6 and
>> libcryptominisat-dev.
> Actually, I think the whole package should be called cryptominisat5.
> That's the name of the project according to upstream [1]. Therefore, I
> guess the library should be libcryptominisat5-5.6, right? About the dev
> package, yes that's a mistake. It should be libcryptominisat5-dev then.
> 
> Or, since people commonly refer to cryptominisat5 as cryptominisat,
> should we just use cryptominisat and libcryptominisat without the "5"?
> 
> julian
> 
> [1] https://github.com/msoos/cryptominisat/issues/468
> 

There are different things and it's important to be consistent in how one separates them.

There's the overall name of the software package, the github project page is called "cryptominisat" and so is your Debian source package. It's best to keep these two consistent.

Then issue 468 talks about the name of the binary, and upstream says this should be cryptominisat5 to avoid getting "into conflicts with old installations". That makes sense. If all binaries are prefixed with "cryptominisat5" maybe it's worth renaming the Debian binary package to cryptominisat5, use your judgement.

Then there is the NAME of the shared library and is what you give to the -l flag for compilers, which judging by the CMakeLists.txt is currently cryptominisat5. So libcryptominisat5-5.6 and libcryptominisat5-dev would be the appropriate package names for the library packages.

On a side note, upstream has an unconventional way of setting SONAME/SOVERSION but it seems fine. Usually SOVERSION is just one number independent of the project major/minor versions, but upstream sets it to project-major.project-minor. As long as they're aware of when to bump it, it's fine - see [1] [2] for details, and note that SOVERSION would normally correspond to [1]'s "current". By contrast cryptominisat upstream's "project-major" vs "project-minor" are kind of useless by themselves for SOVERSION purposes, since under their unconventional scheme "5.1" are equally as incompatible "5.2" as "5" and "6" would be. libcryptominisat5-34 would have been fine (SOVERSION = 34), there is no need to start the SOVERSION with a "5." since it's already part of the library name.

X

[1] https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
[2] https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git