Move GAP to ::gentoo?

[orlitzky]

I noticed that most of the hacks and patches for GAP are now gone. Would it be feasible to move it into ::gentoo now along with the recommended set of packages?

The eclass and the new dev-gap/ category would have to be posted to the mailing list but we could start a PR and work on it there to get the benefit of the CI.

[kiwifb]

A shocking but interesting proposal. The eclass certainly improved the overall quality of the dev-gap/ ebuilds. But I still feel there are dirty bits. And of course the gap package collection is rather limited but that could be incrementally improved if more people are able to work on this.

In other news, suitesparse 7.2.0 is coming. It won't restore multi build, but it will fix a number of kinks related to gpu library builds. So, I will push for that when it happens.

[orlitzky]

It shouldn't be that surprising, it's one of the few packages we're missing that sage's ./configure script can detect. It's always been on the TODO list, it was just more scary in the past.

I recently taught ./configure to detect python packages with --enable-system-site-packages, so once again I've been working on getting the number of SPKGs I have to build down to zero. We're not too far away from being able to build sage[-doc -notebook] using only packages from ::gentoo. ipython needs an update in sage, and I'm going to wait for cython-3.x before I spend any time on that, but there are no big glaring problems remaining.

[kiwifb]

Definitely a lot less scary now. The dependencies between gap-core and gap-packages may still be a bit shaky, but not much more than other ecosystems out there. I'll need to make sure the documentation of the eclass is complete and then we can put up a massive PR.

[orlitzky]

I took a look at the eclass and don't see anything problematic. Double-bracket bash tests like [[ -d foo ]] are preferred over the POSIX single-bracket form, and the lines should be wrapped at 72 chars. Nothing else stands out to me. Possible the -d test before find ... -delete is redundant?

[kiwifb]

Inspecting the overlay, should we start by a PR for sci-libs/libsemigroups? This is needed for dev-gap/semigroups. Or should we just include it in the gap giant PR?

[orlitzky]

Inspecting the overlay, should we start by a PR for sci-libs/libsemigroups? This is needed for dev-gap/semigroups. Or should we just include it in the gap giant PR?

I've almost added libsemigroups a hundred times because ./configure tells me it's missing, but then I remember that it's optional. Can we do only the standard/required packages at first? Basically what's in MINIMUM_PKGS in the gap ebuild, and the dependencies of gap-recommended. Although I think we should probably have USE=minimal disable the gap-recommended packages to eliminate the metapackage now that I think about it.

[kiwifb]

Currently sci-mathematics/gap does not depend on dev-gap/gap-recommended. So, we are in the always "minimal" situation. You think that should be changed?

[orlitzky]

Is this comment still true?

By default gap will complain if those are missing

I'm just worried that once GAP is in ::gentoo, people who have never heard of sage will install it because they want to use GAP, and we should give them what they expect out-of-the-box (unless they set USE=minimal).

[kiwifb]

Can be double checked but I am fairly sure that lib/package.gi has code to complain. I am not sure how and why I removed that dependency in fact. I will need to do a bit of archeology. It may have gone when I flip-flopped with a gap meta-package pulling gap-core and gap-recommended. So, restoring the dependency would make sense.

[kiwifb]

I just noticed polymake is gone \yesterday. So, dev-gap/polymaking which was always masked is gone. Technically it is a runtime dependency of HAPcrystal, hopefully it is optional.

[orlitzky]

I just noticed polymake is gone \yesterday.

I had to mask it, and someone else eventually removed it. Some polymake internals are married to perl-5.36 and upstream has no immediate plans for a fix. Fedora and Debian are dropping it too IIRC.

[fingolfin]

Note that polymake has since then been "resurrected" to work with newer perl versions thanks to some hackery by the polymake devs. I don't know if it has been restored by Fedora and Debian, though...

[orlitzky]

No worries, I brought it back to Gentoo already, and am planning to add the polymaking GAP package as well soon.

[orlitzky]

I should probably mention the draft PR here: https://github.com/gentoo/gentoo/pull/34472

[fingolfin]

cool

[orlitzky]

Done!