V Wed, Nov 03, 2021 at 01:45:00AM +0100, Miroslav Suchý napsal(a): > Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a): > > === 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. > > Devil advocate here: > > **Some** people wipe `/var/lib/rpm` to save 5.9 MB. And because of this we > will put another 5.9 MB [citation needed] as metadata split across various > ELF objects for **everybody**. > > When someone want really tiny image, I will expect they will start stipping > ELF objects when they discover this feature. > Morover it only pertains ELF. What about other files? E.g. compiled Java classes, or minified JavaScript libriaries? What about storing the RPM package identifier by a package manager when installing a file into an extedned attribute of the file? That would track origin of all files and users not intersted in the tracking could easily remove the data. Effectively it would become a feature of the package manager. Not of a build system. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
