[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