https://bugzilla.redhat.com/show_bug.cgi?id=1885430 --- Comment #22 from Carl George 🤠 <carl@xxxxxxxxxx> --- > In the spec we were renaming .so.0.0.0 into .so.%{soversion}.%{version} and then creating symlinks to .so.%{soversion} I'm not an expert in C libraries, but in a situation like this I'd prefer to follow the pattern of other Fedora libraries. Here are a few examples. curl-7.73.0-2.fc34: libcurl.so -> libcurl.so.4.7.0 libcurl.so.4 -> libcurl.so.4.7.0 libcurl.so.4.7.0 yelp-3.38.1-1.fc34: libyelp.so -> libyelp.so.0.0.0 libyelp.so.0 -> libyelp.so.0.0.0 libyelp.so.0.0.0 rpm-libs-4.16.0-3.fc34: librpm.so -> librpm.so.9.1.0 librpm.so.9 -> librpm.so.9.1.0 librpm.so.9.1.0 libxcb-1.13.1-6.fc34: libxcb.so -> libxcb.so.1.1.0 libxcb.so.1 -> libxcb.so.1.1.0 libxcb.so.1.1.0 You can see that the main library file with three digits is used as-is (not renamed), with symlinks for the other names. They do not include the software version in the library file name. Why does qatlib need to rename the library file to include the software version? I think the following file layout is what we should go with. Can the Makefile be adjusted to produce this? libqat.so -> libqat.so.0.0.0 libqat.so.0 -> libqat.so.0.0.0 libqat.so.0.0.0 libusdm.so -> libusdm.so.0.0.0 libusdm.so.0 -> libusdm.so.0.0.0 libusdm.so.0.0.0 It's ok to glob these files as long as it doesn't conceal the major version, so this is what I'd put in the %files section. %{_libdir}/libqat.so.%{libqat_soversion}* %{_libdir}/libusdm.so.%{libusdm_soversion}* > The repo is now created, however the qatlib component is not visible yet in bugzilla. I'm not sure if this is just a delay, or if it needs some other event first such as the first build in koji. Check back on this task after the first build is done. -- 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 To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx