[gentoo-science] Future of the packaging of SuiteSparse

[gentoo-science] Future of the packaging of SuiteSparse

[François Bissey]

Hi all,

Upstream SuiteSparse has started to use cmake in earnest to configure 
and install individual component. This currently in beta to which I have 
given feedback.

There are several issue with suitesparse as it is. Right now we split it 
using a script that I forked from an original work from bicatali 
(Sebastien Fabbro).
The main issue is that upstream only release a meta package and we split 
it. The version of the meta package and of suitesparseconfig increase 
but for the other components some increase and some not.
Issues:
* on one occasion a package was changed without version bump
* version numbers of each packages are stored in two locations in most 
of the packages. And occasionally they do not match, the higher one 
should be kept but this is a pain in the automation.

With the current upstream packaging I'd rather move to using the 
upstream meta package tarball for everything. Mainly because some 
components are currently shared. Splitting would mean copying the 
components as needed in individual packages.
Which also leaves us with the version numbering issue. Do we keep 
individual versions or switch everything to the version number of the 
meta package? The later is convenient and make sure the tarball has some 
version relating tot he ebuild version number.
It is also a bit redundant for packages that don't evolve much.

But it is very convenient and I have used the later for my current 
development.

Find$pkg.cmake files are shipped at install time, but not .pc files. The 
current ones are produced by the splitting script.
I identified only one downstream package that uses the .pc files: 
cvxopt. Removing the use of suitesparse .pc files in cvxopt is 
straightforward and should lead to any issues as suitesparse doesn't put 
anything in weird location of use sub folders that need to be known at 
compile time.

I am very of the mind that we should stop the splitting. Versionning of 
the individual packages is a bit in the air but following the meta 
package versioning is the easiest maintenance wise.

Opinion, suggestions?

Cheers,
François

Re: [gentoo-science] Future of the packaging of SuiteSparse

[François Bissey]

On 7/11/22 14:55, François Bissey wrote:
> I am very of the mind that we should stop the splitting. Versionning of 
> the individual packages is a bit in the air but following the meta 
> package versioning is the easiest maintenance wise.

Writing down stuff and posting it helps to think about it. Following the 
meta packaging versioning may break tracking with repology, so best to 
avoid it.

Other stuff that I should mention:
doc building will not happen with the current cmake implementation. Meta 
building is still handled by a makefile with some options and docs are 
still built by the generic makefiles.

Same with test suites. We currently use "Demo" as test suites. They can 
be built from cmake (at least in some of the packages) but they are not 
currently executed and tested by cmake.

openmp: is currently automagic for most packages supporting it. Used if 
found. I can work with upstream to turn it off if necessary.y

Upside: cuda is handled fairly well by cmake compared to autoconf.

François

Re: [gentoo-science] Future of the packaging of SuiteSparse

[François Bissey]

While not quite in the best way, I have stuff for doc building and basic 
testing ready for when 6.0.0 finally comes out.
I may want to add a few ebuilds since not everything is currently shipped.

On 7/11/22 16:04, François Bissey wrote:
> doc building will not happen with the current cmake implementation. Meta 
> building is still handled by a makefile with some options and docs are 
> still built by the generic makefiles.
> 
> Same with test suites. We currently use "Demo" as test suites. They can 
> be built from cmake (at least in some of the packages) but they are not 
> currently executed and tested by cmake.

François

Re: [gentoo-science] Future of the packaging of SuiteSparse

[François Bissey]

The following are now visible in the main branch of the sage-on-gentoo 
overlay for anyone wanting to have a peek and anyone to comment.
The SuiteSparse meta package is provided at version 6.0.0-beta9.
The following packages are provided (and really all are beta)

* suitesparseconfig-6.0.0_beta9
* amd-3.0.0
* camd-3.0.0
* colamd-3.0.0
* ccolamd-3.0.0
* cxsparse-4.0.0
* cholmod-4.0.0
* btf-2.0.0
* klu-2.0.0
* ldl-3.0.0
* spex-2.0.0 [new]
* rbio-3.0.0 [newish, was already in overlay but not in tree]
* spqr-3.0.0
* umfpack-6.0.0

* dev-python/cvxopt-1.3.0-r1 [the ebuild needs an update to cope with 
the fact that no .pc files for suitesparse components are provided anymore]

Not packaged
* SuiteSparse_GPURuntime
* GPUQREngine
* cuda build option for spqr-3.0.0. It depends on the two above that I 
cannot build or test without a nvivida gpu and cuda.
* moongoose - shipped with suitesparse for convenience. Available elsewhere.
* GraphBLAS - shipped with suitesparse for convenience. Available elsewhere.

François