On Sat, Feb 18, 2023, 18:20 Gordon Messmer <gordon.mess...@gmail.com> wrote:
> On 2023-02-18 04:40, Björn Persson wrote: > > The Detailed Description describes the problem thoroughly, but fails to > > describe the solution. > > Thanks. I'll make sure that it does before formally proposing it, > assuming that we proceed to that point. > > > Unanswered questions include: > > > > · What exactly will be added to the dependencies? > > · How will the dependencies be generated? > > · Will packages require the version of a library that was present when > > they were built, even if they don't use any new interfaces? > > · Will they require that exact version, or that version or newer? > > · Will this make it even harder to achieve the ideal of reproducible > > builds? > (snip) > For shared libraries without versioned symbols, the provides will change > from: > > Provides: libnghttp2.so.14()(64bit) > > to: > > Provides: libnghttp2.so.14()(64bit) >= 14.24.1 > > ... while requirements on that package will change from: > > Requires: libc.so.6(GLIBC_2.3.4)(64bit) > Requires: libnghttp2.so.14()(64bit) > > to: > > Requires: libc.so.6(GLIBC_2.3.4)(64bit) > Requires: libnghttp2.so.14()(64bit) >= 14.24.1 > > Note that dependencies that do have versioned symbols are not affected > by this change. > Dependencies are generated using dlmopen() to locate a required library > named in an ELF header, and then resolving the symlink to a full path. > If the full path ends in ".so.x.y.z", where "x.y.z" is a series of > numbers separated by dots, then the numbers and dots suffix is treated > as a version number for that library. > I see a big hole in that problem (assuming that I understand Things correctly): What happens to packages where this .so.x.y.z pattern does not match their actual version? I have seen many packages that don't follow this pattern, for example, some keep .so.0.0.0 forever and just bump the library name instead of the soname (looking at you, mutter). Others bump their soname very rarely, so the library itself might have version 2.3.4 but the soname is still at libfoo.so.1.0.0. The opposite also happens, with packages bumping soname basically with every release, so libfoo 0.11.2 can provide libfoo.so.143.0.0 ... While I don't think this proposal needs to take account all weird things upstream projects do with their sonames and soname bumping policy (if they have one), it needs to be taken into account by this proposal ... because if I understand this "before" and "after" comparison correctly, the new scheme will generate broken Requires on libraries that don't follow the "I am version x.y.z and hence my major soversion is x" scheme (which is a lot of libraries). Fabio PS: Sorry for possibly broken formatting. I am away from my Linux desktop this weekend. > Packages will require a version of their ELF dependencies equal to or > greater than the version present in their build environment. > > This is not expected to make it more difficult to achieve reproducible > builds, because reproducible builds require that the build environment > have the same contents in order to have the same output. If anything, > this provides a strong hint as to what the build root looked like in > cases where the information is present. > _______________________________________________ > 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 >
_______________________________________________ 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
