Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 03, 2021 at 09:39:28AM +0100, Petr Pisar wrote:
> > 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**.

This was already answered before, but since the thread is long, I'll repeat it:
if you have 5.9 MB in /var/lib/rpm, this means that you have just a handful of
packages, so the overhead of the ELF metadata would be *much* less than 5.9 MB.
The overheads scale ~linearly with the number of files/packages, and you're now
comparing a measurement for a minimal installation (the example was about an
initrd!) with a measurement for a full-throated installation (30000 ELF files!).

> > 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?

Those don't crash ;) so they are outside of the scope of interest of systemd-coredump.

But FWIW, I think it could be interesting to inject similar information into
other formats. I probably wouldn't bother with single classes, but it
could be interesting to inject a META-INF/MANIFEST.MF with similar
info into the .jar files we build. This is clearly outside of the scope of
*this* proposal, but since people do copy .jar files around, I think it'd
make a lot of sense.

> What about storing the RPM package identifier by a package manager when
> installing a file into an extedned attribute of the file?

xattrs are attached to the file itself, so by the time try to collect
the coredump, they may be already gone or out of date. The note has
the advantage that the loader puts it in memory for us, so we get it
when the object is loaded from disk.

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux