* Gordon Messmer: > ## Approaches to consider: > > We could use the DSO version, extracted from the symlink. In this > case, the expat-2.7.3 package would provide "libexpat.so.1()(64bit) = > 1.11.1" and any package that links to libexpat.so.1 would require > "libexpat.so.1()(64bit) >= 1.11.1"
I don't think that's a good approach because upstreams do not necessarily maintain these version numbers in a way that makes this version check meaningful. We need a way to override upstream versioning decisions without having to alter the ABI at the ELF level. > One drawback to this approach is that a dependent binary package would > require expat 2.7.3, even if they did not use any of the symbols that > are new in that version, relative to expat-2.7.1. Some users might > want to build on a system with expat-2.7.3 and deploy on a system with > expat-2.7.1, as long as the binary is able to execute. Adding a more > specific version to the requirement would result in dnf updating expat > when the new binary is installed. For Fedora, this doesn't seem to be much of a problem because due to various factors, most software has to be built in a version-specific buildroot. Portable binaries need to be built outside of Fedora. I don't think it will meet developer expectations downstream, though. > It's also nearly identical to the work required to simply add > versioned symbols to shared libraries, which is a much better option, > and doing the same amount of work to get a result that isn't as good > doesn't make sense to me. Not all build systems support this in a convenient way, and doing it downstream only would make the binaries Fedora-specific. Thanks, Florian -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
