== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek(a)in.waw.pl
* Name: Lennart Poettering
* Email: mzsrqben(a)0pointer.net
All binaries (executables and shared libraries) are annotated with
an
ELF note that identifies the rpm for which this file was built. This
allows binaries to be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses this to log package
versions when reporting crashes.
This feature was rejected, and rightfully so. Resubmitting it for the very
next release is not a constructive thing to do.
== Detailed Description ==
People mix binaries (programs and libraries) from different
distributions
Mixing binaries from different distributions has always been a bad idea.
(for example using Fedora containers on Debian or vice versa),
Containers ought to include the (guest) distribution's package database.
Everything else is just broken and needs to be fixed.
and distribute binaries without packaging metadata (for example by
stripping everything except the binary from a container image, also
removing `/usr/lib/.build-id/*`)
In the vast majority of cases, it is actually illegal to do so. Most
software in Fedora is under copyleft licenses that requires distributors to
include the complete source code, including build scripts, which in practice
means the SRPM. Distributing just the binary ripped from an RPM package,
without any pointer as to where it comes from, is a blatant violation of any
such copyleft license.
compile their own rpm packages (for internal distribution and
installation)
Then the binary will be tracked by the RPM database, and this feature is not
of any use in that use case.
and compile and distribute their own binaries.
In which case it is entirely irrelevant whether Fedora binaries include the
proposed metadata or not. It is the decision of whoever compiles the
binaries whether and how to annotate them.
=== Why not just use the rpm database? ===
<pre>
17:34:33 <dcantrell> The main reason for this appears to be that we
need the RPM db locally to resolve build-ids to package names. But
since containers wipe /var/lib/rpm, we can't do that. So the solution
is to put the ''nevra'' in ELF metadata?
17:34:39 <dcantrell> That feels like the wrong approach.
</pre>
First, there are legitimate reasons to strip packaging metadata from
images. For example, for an initrd image from rpms, I get 117 MB of
files (without compression), and out of this `/var/lib/rpm` is 5.9 MB,
and `/var/lib/dnf` is 4.2 MB. This is an overhead of 9%. This is ''not
much'', but still too much to keep in the image unless necessary.
Similar ratios will happen for containers of similar size. Reducing
image size by one tenth is important. There is no `rpm` or `dnf` in
the image, to the package database is not even usable without external
tools.
So you propose to add bloat to all ELF binaries for everyone so that people
can delete an integral part of a working Fedora installation to save some
space? How is that a reasonable tradeoff?
As discussed on IRC
(
https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-05-11-17.01.log....),
the containers ''we'' build don't wipe this
metadata, but custom
Dockerfiles do that.
And those Dockerfiles are broken, any bug reports from them (i.e., where the
package information is missing in the report) should be closed as
INSUFFICIENT_DATA immediately.
Second, as described in Description section above, not everybody and
everything uses rpm. The Fedora motto is "we make an operating system
and we make it easy for you to do useful stuff with it" (and yes, this
is an actual quote from the official docs), and this stuff involves
reusing our binaries in containers and custom installations and
whatnot, not just straightforward installations with `dnf`. And in the
other direction, people will build their own binaries that are not
packaged as rpms. But it is still important to be able to figure out
the exact version of a binary, especially after it crashes.
See above: If they build their own non-RPM binaries, what difference does it
make whether we enable those annotations for the binaries built as part of
our RPMs? Whether our binaries are annotated and whether their binaries are
annotated are entirely orthogonal decisions made by who builds each binary.
https://hpc.guix.info/blog/2021/09/whats-in-a-package/ contains a
nice
description of a pathological case of packaging hacks and binary
redistribution. When trying to unravel something like this,
information embedded directly in the binaries would be quite useful.
As explained above, those upstreams are illegally redistributing the library
binaries. Why should we do anything that helps them do that?
Incidentally, this is also why we need to package software properly in
Fedora instead of pointing users to distro-within-the-distro tools such as
pip that reinvent the packaging wheel and have no good way to deliver
compiled C/C++ dependencies. (They can only either build everything from
souce on the user's machine or ship some blob compiled somewhere on some
distribution, because they do not integrate with the native RPM packaging
and so cannot use the C/C++ libraries Fedora ships.)
Kevin Kofler