https://bugzilla.redhat.com/show_bug.cgi?id=1357724



--- Comment #16 from Susi Lehtola <susi.leht...@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
_______________________________________________
package-review mailing list
package-review@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/package-review@lists.fedoraproject.org

Reply via email to