Spurred off of the recent lxqt thread in devel (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...) 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?

On Mon, 3 Jan 2022, Ian McInerney wrote: > Spurred off of the recent lxqt thread in devel (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...) 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_share...

On Mon, 2022-01-03 at 19:30 -0500, Neal Gompa wrote: > On Mon, Jan 3, 2022 at 7:08 PM Scott Talbert <swt(a)techie.net&gt; wrote: > > > > On Mon, 3 Jan 2022, Ian McInerney wrote: > > > > > Spurred off of the recent lxqt thread in devel > > > (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... > > > ) 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_share... > > > > Something I've done in openSUSE and Mageia that might be worth doing > in Fedora is a namespaced glob, where the somajor is specified and the > sublevels are globbed. > > You can see an example of this with my fdk-aac-free package in > openSUSE here: > https://code.opensuse.org/package/fdk-aac-free/blob/4d35a883c89e7569349fc... > > Admittedly, it's a lot easier for me to do it this way in openSUSE and > Mageia rather than Fedora since I also need to name the library > packages with the somajor in them... we do this in several packages, one is opencv https://src.fedoraproject.org/rpms/opencv/blob/rawhide/f/opencv.spec#_395

Neal Gompa wrote on 2022/01/04 10:00: > On Mon, Jan 3, 2022 at 7:57 PM Sérgio Basto <sergio(a)serjux.com&gt; wrote: >> >> On Mon, 2022-01-03 at 19:30 -0500, Neal Gompa wrote: >>> On Mon, Jan 3, 2022 at 7:08 PM Scott Talbert <swt(a)techie.net&gt; wrote: >>>> >>>> On Mon, 3 Jan 2022, Ian McInerney wrote: >>>> >>>>> Spurred off of the recent lxqt thread in devel >>>>> (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... >>>>> >>>>> ) 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_share... >>>> >>>> >>> >>> Something I've done in openSUSE and Mageia that might be worth doing >>> in Fedora is a namespaced glob, where the somajor is specified and the >>> sublevels are globbed. >>> >>> You can see an example of this with my fdk-aac-free package in >>> openSUSE here: >>> https://code.opensuse.org/package/fdk-aac-free/blob/4d35a883c89e7569349fc... >>> >>> >>> Admittedly, it's a lot easier for me to do it this way in openSUSE and >>> Mageia rather than Fedora since I also need to name the library >>> packages with the somajor in them... >> >> >> we do this in several packages, one is opencv >> https://src.fedoraproject.org/rpms/opencv/blob/rawhide/f/opencv.spec#_395 >> >> > > That version is not as precise, because you use "%{abi_ver}*" (where > %abi_ver is defined as 4.5), which means that 4.5.1 and 4.51 would > both match, and that's not exactly what you want. > > If you do "%{abi_ver}{,.*}", it would match _only_ 4.5 and 4.5.*, so > there's no chance of a bizarre ABI bump slipping through. > Rather now I am surprised that rpm spec supports this bash-like brace expansion.

I would have used this syntax if I had already knew this. Maybe there is some documents or specification of what rpm spec supports, however it is too difficult for me to read all of such documents beforehand... Regards, Mamoru _______________________________________________ packaging mailing list -- packaging(a)lists.fedoraproject.org To unsubscribe send an email to packaging-leave(a)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/packaging@lists.fedoraproje... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure