https://bugzilla.redhat.com/show_bug.cgi?id=1357724 --- Comment #9 from Susi Lehtola <susi.lehtola@xxxxxx> --- (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 _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx