Re: Boost

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Wed, 19 May 2021 11:02:28 +0000
schrieb nia <nia%NetBSD.org@localhost>: 

> I think there's a strong argument for the boost packages
> to be versioned - currently so much breaks every time a new version
> is released, and someone's toes get stepped on.
> 
> Clearly there are people that want the newest version, but I can't
> stand repeatedly patching the same software every time a boost update
> is committed.

I am ambivalent about this. Somehow relying on Boost means that
upstream wants to be at the bleeding edge of C++. Pinning old versions
means that the package maintainer will have to periodically check what
the newest compatible boost version is and change the dependency, for
each package that otherwise might never have an issue with updates.

You should consider the complexity introduced by having multiple
versions of boost in the tree. You could end up with multiple boost
versions in one dependency graph. Modern C++ stuff likes to use other
modern C++ stuff and you easily get tangled up.

Depending on Boost just sucks. There's no way around the hurt. The
question is if it is really helped by introducing versioning. Packages
using Boost will have to adapt to changes sooner or later anyway. I
think there should be a clear testing regime (is there a shortcut to
(re-)build all dependees when working on the boost packages?) on
updates and clear criteria how long to abstain from from Boost updates
if they break too much. Simply wait for the dust to settle.

Usually, you'd hunt for the needed patches on upstream bug trackers and
new releases will follow with the compatibility fixes anyway. What this
also means is that one might have to be rather strict in killing off
unmaintained software that suffers from Boost, or introduce certain
versioned boost packages for these cases only if the respective package
is too important and too hard to fix.

> Most others seem to have had the same idea:
> 
> https://repology.org/project/boost/versions

Could you elaborate on that? This does not seem apparent to me. In the
case of Ubuntu 20.04, there indeed is a set of packages for Boost 1.67
in addition to the default 1.71, but they do conflict with each other.
They are _not_ versioned to be installed at the same time.

The 1.67 packages live in the universe, not in the core package set.

The versioned shared libraries can be installed alongside each other,
but the development packages with static libs and headers do not. This
is a hack for supporting old binary packages, or the case I outlined
above of having a special version of boost libs for select packages
that cannot be fixed to build with the default version.


Alrighty then,

Thomas

PS: There's even something horrible like libboost-mpi-python1.71-dev or
libboost-numpy1.67-dev … you got Boost versions, MPI implementations,
Python versions, all combined! This madness needs to be limited where
possible.

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg