On Wed, Oct 27, 2021 at 03:24:07AM +0200, Kevin Kofler via devel wrote: > > == 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. How so? It was rejected with the request to enhance the motivation section and to answer some specific questions about upgrades. This has been done. Why do you say an update to a proposal that answers the issues that were raised should not be resubmitted? > > == 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. It's much more complicated than that and you know it. 1. The strong copyleft licenses allow an offer for the source code OR the source code, and most people pick the first. 2. A lot of software is under permissive licenses, which don't require this. 3. And actually if the software is not *distributed*, i.e. stays within one organization, all of this doesn't even apply. 4. And even when distributing software, you can have a proposal or a link to a download at the place where the software is distributed, nothing obliges *the user* to always download and install both. 5. This proposal is not about licensing, but if it is adopted, it'll only make figuring out potential licensing violations easier (in some cases, primarily when distributing without recompilation). > > 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? "bloat" == couple hundred of bytes. Note that this is only for *compiled* objects, which have a few kilobytes of ELF header even in the simplest cases. Please see the original proposal for a discussion of various circumstances where this additional information is useful. > > 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. The fact that you don't like what somebody else is doing doesn't make it "broken" or a "blatant violation of ... license". As discussed in the other part of my reply, you're just making very general far-fetched statements that may be true in some cases, but are trivially shown to be groundless in many other cases. > > 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. Yes. > > 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. No. Not (in general) "illegally", not "redistributing", and not "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. This is a completely unrelated subject. Let's not go there. > (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.) It seems to me that you dislike how some people are distributing software, and on this dislike you want to build technical and legal discussion. Sorry, but your analysis of what licensing implies is just baseless, and I don't think we're going to force people to stop using docker and pip and curl by not adding metadata to rpms. Zbyszek _______________________________________________ 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
