> == Owner == > * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek@xxxxxxxxx > * Name: Lennart Poettering > * Email: mzsrqben@xxxxxxxxxxxx > 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.html), > 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 _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
