https://bugzilla.redhat.com/show_bug.cgi?id=1885430
--- Comment #25 from Carl George š¤ <c...@redhat.com> ---
> BTW, I also checked other libraries and it seems that there isn't
> consistency. For e.g. this is the approach used by libc:
> libc.so.6 -> libc-2.32.so
> libc-2.32.so
> libc.so
The majority of libraries follow the pattern I described. I didn't claim 100%
consistency. :)
> In any case, is the realname of the library a problem?
> In the current schema the realname updates at every release and it is
> independent from the fully qualified soname (which includes the soversion).
> Applications will be using the fully qualified soname and not referring
> directly to the realname.
It's a problem if it can be confused with the soversion. And since
applications will reference the soversion, it's unnecessary to include the
software version in the library filename at all.
> In order to be able to detect the version we can add an additional symlink
> that includes in the name the version of the library:
> libqat-20.10.so -> libqat.so.0.0.0
I'm ok with a symlink like this because it avoids confusing the software
version with the soversion, similar to how libc is named. Make sure to add
those symlinks to the %files section.
%{_libdir}/libqat-%{version}.so
%{_libdir}/libusdm-%{version}.so
> If this option is preferred we need to go for an additional upstream release
> (I have a patch already for that). It might take a couple of days to get it
> approved due to the internal process.
Instead of waiting for the new upstream release, you can just include the patch
in the spec file (Patch0: <name>.patch) and apply it during %prep. You're
already using %autosetup, you'll just need to add a -p1 flag (assuming the
strip offset of your patch is 1, which is pretty standard). Make sure to
include either a comment explaining the patch or a link to an upstream
issue/pull request/commit, as described in the patch guidelines [0].
[0]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_patch_guidelines
--
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
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
