On Mon, 3 Jan 2022, Ian McInerney wrote:
Spurred off of the recent lxqt thread in devel (https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/DBK3A4KMS7P3MX6FLXQYNTA665T6X433/) that bumped the soname for another library in the stack without announcing that one, I looked in the packaging guidelines to see if there was anything about how to represent the soname version in the spec and didn't see anything.
I know I have seen some mention on the devel list about using a global
define to set the so version, and then using that in the %files section
instead of a glob on the shared library so that an so version bump is
caught at build time and errors it without packager intervention, but
that doesn't appear to be listed in the packaging guidelines at all.
What are people's thoughts on adding a section about handling so
versions alongside the soname section? It say to use the global
define/no glob method in the spec (although I haven't decided if I think
it should be a SHOULD or a MUST criteria). I feel that could help reduce
these unannounced breakages that seem to crop up and that are annoying
to scramble to fix afterwards.
Thoughts? Or did I overlook a place in the packaging guidelines that
already discusses this?
There's this section[1] that states that you SHOULD NOT use a glob for
%files, but it doesn't talk about using a macro.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
Scott
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure