tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re:, etc. version numbers? (working on wip/cblas and wip/lapacke)

On 06/11/18 10:54, Dr. Thomas Orgis wrote:
Am Mon, 11 Jun 2018 09:46:26 -0500
schrieb Jason Bacon <>:

The soversion doesn't necessarily correspond to the major distversion.
Yep. I manage mpg123, where the library is at 0.44.6 for project
version 1.25.7. Re-reading documentation about library version numbers
suggests to me that not making the distinction mainly excludes the
option to have a backwards-compatible major version increment. As long
as they never introduce LAPACK 4.x, things will work out … well and as
long as nobody prematurely started shipping builds of the libraries
with made-up soversions.

It appears that Netlib BLAS and LAPACK don't even have a concept of
soversions upstream and this
may be somewhat arbitrarily tacked on by the package manager for its own
Spot on … at least for the Makefile-based build. Pkgsrc just hacks
the shared lib builds with patches.

I just looked at the FreeBSD port for perspective and it uses an
soversion of 1 for the lapacke slave
port, 2 for the blas slave port, and 4 for the lapack master.  The cblas
port forces an soversion of 2.
Interestingly, lapacke is an lapack slave, but cblas is not.  Both get
their sources from netlib, though,
as does pkgsrc-wip cblas.
I'd like to hear from the blas/lapack maintainer(s) on the soversion.
Wonderful mess we got there. Did you ask them?

What would be the benefit of using cmake?  Unless it's significant (e.g.
upstream plans to require it in the near future),
I wouldn't want to add such a big and painful dependency.
Agreed. But using cmake, we can discern what netlib folks might think
about regarding shared libraries and versioning:

$cmake -DBUILD_SHARED_LIBS=ON ../lapack-3.7.1
$find . -name '*.so*'

There now is the precedence of just putting the project
version number in there, implying that a future version 4.x will be
ABI-incompatible … and we might have to switch from 4.0 to 3.7.1 or

We _could_ just ignore upstream and continue to use made-up numbers.
But everyone else having (or even in the case
of FreeBSD?!), while pkgsrc features with the same
contents, looks odd.

Can we get an explanation for why pkgsrc decided on .so.4?

Alrighty then,


I would be inclined to cooperate with upstream's choice of soversion, but this does present a potential problem of an soversion going backwards with the next update.  I'm not sure what the ramifications are for pkgsrc...

In my view this also provides a legitimate reason to consider using cmake in the package.  It will eliminate some high-maintenance hackery from the package and the need for posterity to spend time discussing the choice of soversion as we're doing now.

Home | Main Index | Thread Index | Old Index