https://bugzilla.redhat.com/show_bug.cgi?id=1357724
--- Comment #9 from Susi Lehtola <susi.lehtola(a)iki.fi> ---
(In reply to Matt Chan from comment #8)
(In reply to Susi Lehtola from comment #7)
> But that's not possible: you're using a version 2.8.6 tarball, while you
> specify version 1.8.6 in the specfile (and work around the discrepancy
> between your numbering and the tarball by specifying version 2.8.6 in the
> %setup).
The github tag is for 2.8.6, which is why the tarball shows up as that. The
version in the documentation etc is 1.8.6. I can ask Qiming to retag it? The
the tag/version should be fixed in a future release though.
Then I think the version is 2.8.6, not 1.8.6.
> Libcint should, however, be the default package to be installed,
because
> qcint doesn't work on all x86_64 machines. I'm not sure how dnf does its
> dependency resolvement, but if it's the same as with yum then the package
> with the shortest name will be picked, and that'd be qcint.
Hmm so you're saying I should change libcint to build on x86_64 as well,
then list it in the pyscf BuildRequires?
AFAIK libcint shouldn't have ExclusiveArch, only ExcludeArch for those
architectures it doesn't build on... Namely those that are lacking some of the
buildrequirements.
Alternatively I could do something similar to what Igor suggested?
But those
few users without SSE3 would have segfaults I think.
%ifarch x86_64
BuildRequires: qcint-devel
%else
BuildRequires: libcint-devel
%endif
This won't do anything, since the library soname is the same in both. The
package would get built against qcint, but when a user installs the package
they might already have libcint installed and so the package would use that.
The only two possible solutions to this are:
- qcint and libcint ship libraries with different sonames, e.g. libqcint.so and
libcint.so => choice of library must be done at compile time
- qcint and libcint share the same API and ship with the same soname => user
may pick which package to install
Actually, there IS a way to circumvent the excludes. Namely, install the
libraries in a directory outside the usual library path, and use e.g. the
alternatives system to pick which implementation should be used. Another choice
would be the environment modules system, which is currently used for MPI
software. But here I think the benefit is rather limited, since a user will
prefer qcint over libcint if it just runs on your hardware.
--
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