On Sat, Feb 18, 2023, 18:20 Gordon Messmer <gordon.messmer@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
