Yet another one that SageMath can detect. This also looks easy: no out-of-tree dependencies, no patches, and the test suite passes.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=60bdaa57a2569f7b1a3167d17aa005b01d1450fa commit 60bdaa57a2569f7b1a3167d17aa005b01d1450fa Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-01-01 20:46:18 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-01-02 14:20:23 +0000 sci-libs/m4ri: new package for dense matrix computations over F2. This package was imported from the sage-on-gentoo overlay with only a few changes: * Updated from EAPI=6 to EAPI=7, and subsequently moved virtual/pkgconfig to BDEPEND. * Put the --enable-png flag behind USE=png. * Enabled the test suite, which passes out-of-the-box for me. * Update the HOMEPAGE to point to bitbucket; it was redirecting. * Updated LICENSE to GPL-2+ from GPL-2 (based on file headers). The SageMath package can detect and use the system copy of m4ri, which means that this package should eliminate pointless rebuilds of m4ri for users of SageMath on Gentoo. Closes: https://bugs.gentoo.org/704500 Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-libs/m4ri/Manifest | 1 + sci-libs/m4ri/m4ri-20140914.ebuild | 54 ++++++++++++++++++++++++++++++++++++++ sci-libs/m4ri/metadata.xml | 33 +++++++++++++++++++++++ 3 files changed, 88 insertions(+)
I am preparing the upstream bump and I need some info on what you have done. What is the point of RESTRICT="!test? ( test )" Is it meant to be something standard? I have don't the test flag on don't test? I am inclined to remove the test useflag and this line. Good news for the new version, the tarball in bitbucket is a sdist. Quite possibly it was one for the old version because bitbucket works differently from github. Also what should we do about https://bugs.gentoo.org/230431
(In reply to François Bissey from comment #2) > I am preparing the upstream bump and I need some info on what you have done. > What is the point of > RESTRICT="!test? ( test )" > Is it meant to be something standard? I have don't the test flag on don't > test? > I am inclined to remove the test useflag and this line. It's something standard now. In the past, portage would do some magic to decide what USE flags to enable and what phases to run based on FEATURES=test. The behavior of "FEATURES" is not covered by the PMS, though, so it would be perfectly legal for the src_test phase to be run with USE="-test" set. That's not what people expect, though, and it will fail when you have things like DEPEND="test? ( dev-util/foo )" because you'll wind up running src_test without pulling in the necessary dev-util/foo. You can see the argument on this mailing list thread: https://archives.gentoo.org/gentoo-dev/message/ee3974a8beb9af6a31a1501f58a949b5 In this case, you're right. As it stands, you could delete the USE flag and the RESTRICT line and everything would be the same. The reason I had it in there is because I think eventually we should have something like BDEPEND="... test? ( ${RDEPEND} )" and then it makes sense to disable the test phase if USE=test is not set (because we won't have the runtime dependencies, which are needed to run the tests, installed). The reason I don't have something like that in BDEPEND *now* is because I don't cross-compile, and I haven't been able to get a straight answer about how it should work in bug 693916. So: if you want to delete it, we could always put it back later. Or if you want to leave it, it doesn't hurt anything. > Good news for the new version, the tarball in bitbucket is a sdist. Quite > possibly it was one for the old version because bitbucket works differently > from github. > > Also what should we do about https://bugs.gentoo.org/230431 Should I just close it?
Thank you for the explanation. I think tackling the problem that way is a bit of a band aid. If we start to do that in every packages that can run tests, it is better moved inside the package manager itself as some boiler plate (TDEPEND?). Of course it may be better than nothing in the cases it counts. I think it is appropriate to close https://bugs.gentoo.org/230431.
