https://bugzilla.redhat.com/show_bug.cgi?id=1357724
--- Comment #16 from Susi Lehtola <susi.lehtola(a)iki.fi> ---
(In reply to Dave Love from comment #15)
(In reply to Susi Lehtola from comment #14)
> Yeah, so the default ATLAS package on x86_64 is non-SSE3, but there's a SSE3
> variant available, as well.
Yes, and it's the ld.so.conf mechanism I think is relevant.
Yeah, I'd just rather avoid the confusion of being able to install both
simultaneously and then have to hack the alternatives configuration to figure
out which one is actually in use.
> Packaging both within the same srpm is not allowed per the
packaging
> guidelines, as there needs to be a spec per tarball.
I don't see where it says that, though you can only have one URL.
I am 99.9% certain this is a rule, i.e., that you can't bundle different
projects together into one spec file. And this is exactly the case here: we
have the original version and a fork of it, that's SSE3-only.
> I believe the ABIs are shared, though.
Apologies, I was confusing libcint and libint, which already has two
versions.
[If they're from the same place, I'd have thought it would be more of an
argument for bundling source with libcint, but I'm not reviewing it.]
No, libcint and libint are totally different projects. They have similar
purpose, though.
Obviously I should stick to pointing out the way hardware-specific
versions
have been handled. That's relevant for those of us who have to support
such things. The way ATLAS does it at least can support heterogeneous HPC
systems using a single image on stateless nodes, where the image system
can make node-dependent mods to the configuration files. [Not that you
should use ATLAS on x86, given OpenBLAS, and you could perhaps handle that HPC case
differently.]
Well, that's true. But most compute clusters have local operating systems, and
it's trivial to pick qcint or libcint on a node basis.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component