* Gordon Messmer: > On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote: >>> ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the >>> version of the package that provides libfoo.so.2 in the build root, which is >>> an idea that's growing on me. >> This is indeed a shortcoming in the rpm symbol dependency generation scheme. >> But there's a problem with the proposed approach: versioning as >> major.minor.micro >> is just a convention, and not all upstream follow it. > > > The version doesn't have to be major.minor.micro, though. The > dependency generator only needs to get the version of the package that > provides the .so, and use that version. As long as changes within a > so version are always backward compatible, and the so version is > bumped when breaking changes are made (which are already constraints > on the existing system), then the proposed solution is reliable. It's > sometimes too strict -- it might require 1.4.3 when 1.4.0 is > compatible -- but it's reliable.
We already do this for glibc in rawhide, for the symbol version under development. # Auto-generating dependencies for glibc development snapshots. # # A glibc development snapshot (say version 2.33.9000) may define # symbols in its under-development symbol version (GLIBC_2.34). RPM # automatically derives RPM dependencies such as # libc.so.6(GLIBC_2.34)(64bit) from that. While the GLIBC_2.34 # version is under development, these dependencies may be inaccurate # and could be satisfied by glibc RPM package versions that lack the # symbols because they were created from an earlier development # snapshot that had some other GLIBC_2.34 symbols. Therefore, if the # latest, under-development ELF symbol version is detected, this # dependency generator adds an explicit RPM dependencies on the glibc # packaging version against which an RPM package is built. <https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.req.in> This is an example build: util-linux-2.38.1-1.fc37 <https://koji.fedoraproject.org/koji/buildinfo?buildID=2042005> (util-linux-core in particular.) Right now, this isn't used much, but it when it is, it causes issues for developers who use the rawhide compose in chroots and newer builds leak into the chroot from the buildroot without a full chroot update. Manually ELN tagging can cause similar issues, so we no longer embed the dist tag in the auto-generated versions. Thanks, Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
