In all the dependent packages, what used to be the "metis" USE flag, has now been renamed to "partition". So currently suitesparse-4.2.1 blocks all of its dendencies from being upgraded because they lack the required "metis" use flag. Simply renaming "metis" to "partition" in the suitesparse ebuild should be sufficient to fix it. Reproducible: Always
Actually, what's really missing here is a meta package for suitesparse-5.4.0. I updated all of the components (corresponding to suitesparse-5.4.0), but I didn't know there was a metapackage.
Is it really useful to have a meta package here? If so, there are two more packages from the suite that should get ebuilds. Unlike the others, those two uses cmake out of the box.
Some time ago, I was working on a solution to this in my overlay, which would use one single package using USE flags to determine which sub-packages get's installed. It's currently on hold but you can take a look at the last state at https://github.com/waebbl/waebbl-gentoo/pull/33 if you're interested. It currently uses the upstream build system. But the build system is very old, using plain Makefiles, with exceptions to the two newer, cmake based packages which Francois mentioned. It would be easier, if the packages have one unique build system. I was thinking of making a cmake based build system for Gentoo, possibly providing it to upstream if it's wanted and when it's finished. If someone has interest in helping with this, we could push it forward.
My understanding is that upstream is interested in moving to cmake eventually. A push and a bit of help would probably be appreciated. I have resurrected biccatali's effort in splitting and autotooling suitesparse and you can find it at https://github.com/kiwifb/suitesparse The approach has limitations. 1) sometimes upstream changes the sources (for minor things) without bumping the version (see https://github.com/DrTimothyAldenDavis/SuiteSparse/releases/tag/v5.5.0 the entry for CXsparse). 2) there are sometimes inconsistency between versions number listed in documentation and the makefile (see https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/KLU/Doc/ChangeLog and https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/KLU/Lib/Makefile#L6). 3) if I improve the generating script above or introduce a fix, I am producing a new set of sources without revision bump. Case in point is that I am stuck with https://github.com/cschwan/sage-on-gentoo/issues/574 (I recommend reading, it is a lesson about portability). In short my generated tarball are not guaranteed to stay the same for a given version of a package. Which of course is bad. The good stuff is the splitting. But moving upstream to use cmake for individual package and may be a cmake superbuild system would go a long way. If individual packages each have their own cmake build system we could still split while doing it from a single source tarball.
Thanks for the pointers. I wasn't aware of the github repository of DrTimothyAldenDavis for SuiteSparse and was always using the homepage. This makes things a lot easier to handle. Using autotools is not an option for me personally, but I appreciate the effort. M4 has tortured me during the last 30 years (from a devs point of view) and I'm happy if I have to use them only as a consumer and don't need to develop with it. My basic idea was in unifying the build and against splitting. While both systems have their advantages and disadvantages, reducing the maintenance overhead from maintaining ~10 packages to one single package was the argument, why I wanted to try this. Using both approaches together could be used for a transition period, but in the long term it would produce even more maintenance burden. A single package could also make inconsistencies between sub packages more easily visible, such as for example bug #716024 and bug #716026 where stable and unstable ebuilds exist in parallel which are in parts incompatible to each other when it comes to building. I forked the upstream git repository and see if I can come up with something useful. I'm no longer a developer in the first place and it's been some time since I last developed anything actively, even if it's only a build system. So, I welcome anybody who wants to collaborate with me on this.
This all sounds like a worthwhile discussion, but right now there is just this very simple inconsistency that can be resolved by renaming the "metis" USE-flag to "partition" in the suitesparse ebuild. Sounds to me like these questions about meta-packages and build systems are independent of that, so let's just give people consistent dependencies first and then think about larger redesigns...?
(In reply to Victor Mataré from comment #6) > This all sounds like a worthwhile discussion, but right now there is just > this very simple inconsistency that can be resolved by renaming the "metis" > USE-flag to "partition" in the suitesparse ebuild. > The dependencies in the suitesparce-4.x metapackage are wrong... they'll accept any newer version of the individual components. Obviously if you install all of the 5.4.0 components, you're not going to wind up with suitesparse-4.x. But for the 4.x components and metapackage, "metis" is the right flag name. In other words, the fact that the flag name becomes "wrong" is only because the dependencies were wrong to begin with. I'm going to commit an updated metapackage in a few minutes with correct dependencies (actually tied to the 5.4.0 versions of the components), and the new USE flag name. This should prompt an update of both the metapackage and the components, which will then all use the new flag name. Unless there's a good reason to keep the old version around, the final step will be to remove the old version and not have to worry about the flag name or the wrong dependencies any longer.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=030d616e0dbb91f18a34fdb6c5cb72024b33915f commit 030d616e0dbb91f18a34fdb6c5cb72024b33915f Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-04-04 13:41:54 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-04-04 14:04:03 +0000 sci-libs/suitesparse: new version 5.4.0. All of the individual suitesparse components have been updated, but I didn't realize there was a metapackage. And the 4.x versions of the metapackage have incorrect dependencies that are trying to pull in the components that belong to suitesparse-5.4.0. This is producing some confusing errors. This commit adds a new version of the metapackage with correct dependencies (tied to the versions of the components that ship with suitesparse-5.4.0), and should let ~arch users upgrade everything after switching from USE=metis to USE=partition. At some later point, we can prune the 4.x metapackage and components and be dont with that. Bug: https://bugs.gentoo.org/711610 Package-Manager: Portage-2.3.89, Repoman-2.3.20 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-libs/suitesparse/metadata.xml | 19 +++++++++++++++---- sci-libs/suitesparse/suitesparse-5.4.0.ebuild | 27 +++++++++++++++++++++++++++ 2 files changed, 42 insertions(+), 4 deletions(-)
Part of trouble is that all current ebuilds install libraries that are "0.0.0" regardless of versions. The latest version of the packaging script at least uses upstream soname which means we could use subslot dependencies. But again that requires to change the sources used by the ebuilds - without changing the version number in most cases.
I noticed today: "A cmake setup for all of SuiteSparse is in progress." in the repositories README.md. AFAIR, the upstream build system doesn't use shared libs at all. I remember, that I had to add makefile targets for shared libraries to at least some of the packages. But {,SO}VERSION variables were present in the makefiles, so it should be possible to install the libraries with their sonames appended.
(In reply to Bernd from comment #10) > I noticed today: "A cmake setup for all of SuiteSparse is in progress." in > the repositories README.md. > > AFAIR, the upstream build system doesn't use shared libs at all. I remember, > that I had to add makefile targets for shared libraries to at least some of > the packages. But {,SO}VERSION variables were present in the makefiles, so > it should be possible to install the libraries with their sonames appended. I have done the package as whole single piece in sage(math) and it does default to dynamic libraries. I would have to check if it just does both but after a little bit of patching to remove some unwanted stuff and add DESTDIR, I just do echo "print configuration" $MAKE MY_METIS_LIB=none CHOLMOD_CONFIG=-DNPARTITION \ BLAS="$(pkg-config --libs blas)" LAPACK="$(pkg-config --libs lapack)" \ INSTALL="$SAGE_LOCAL" DESTDIR="$SAGE_DESTDIR" config # build and install $MAKE MY_METIS_LIB=none CHOLMOD_CONFIG=-DNPARTITION \ BLAS="$(pkg-config --libs blas)" LAPACK="$(pkg-config --libs lapack)" \ INSTALL="$SAGE_LOCAL" DESTDIR="$SAGE_DESTDIR" install For a trivial configuration and I get shared libraries.
You are right. I only saw the static libs code in the makefiles on a quick glance.
This will eventually be sorted out in bug #716960 when the new suitesparse is stabilized and I can delete the old metapackage with the incorrect dependencies.
