On Wed, Oct 27, 2021 at 09:41:05PM +0200, Miroslav Suchý wrote: > Dne 27. 10. 21 v 21:35 Luca Boccassi napsal(a): > >>??? The build-id can be > >>always retrieved from the dnf repository. > >> > >>Miroslav > >Which dnf repository? What if it's not dnf but apt? Or zypper? What if it's none? How do you know? > > In repository in general (can be deb, zypper, local directory). Even the > offline systems have some repository where they get the packages from. I tried to answer that in the Change text. tl;dr: yes, it's possible, but often hard in practice. Quoting https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#Detailed_Description > When the need to introspect a binary arises, we have some very good > mechanisms to show the provenance: when a file is installed through > the package manager we can directly list the providing package, but > even without this we can use build-ids embedded in the binary to > uniquely identify the originating build. But those mechanisms work > best when we're in the realm of a single distribution. In > particular, build-ids can be easily tied to a source rpm, but only > when the source rpm is part of the distribution and the build-id was > registered in the appropriate database which maps build-ids to real > package names. When we move outside of the realm of a single > distribution, it can be hard to figure out where a given binary > originates from. If we know that a binary is from a given > distribution, we may be able to use some distro-specific mechanism > to figure out this information. But those mechanisms will be > different for different distributions and will often require network > access. > > The directly motivating use case is display of core dumps. Right now > we have build-ids, but those are just opaque hexadecimal numbers > that are not meaningful to users. We would like to immediately list > versions of packages involved in the crash (including both the > program and any libraries it links to). It is not enough to query > the rpm database to do the equivalent of rpm -qf …: very often > programs crash after some packages have been upgraded and the > binaries loaded into memory are not the binaries that are currently > present on disk, or when through some mishap, the binaries on disk > do not match the installed rpms. A mechanism that works without rpm > database lookup or network access allows this information to be > showed immediately in coredumpctl listings and journal entries about > the crash. This includes crashes that happen in the initrd and > sandboxed containers. > > A second motivating use case is when users distribute their own > binaries and would like to collect crash information. Build-ids are a > solution that is technically possible, but easy to get wrong in > practice: users would need to immediately record the build-id after > the build and store the mapping to program names, versions, and build > number in some database. It's much easier to be able to record > something during the build in the build product itself. > > A third motivating use case is the general mixing of Fedora binaries > with programs and libraries from different distributions, both with > our binaries being used as the base for foreign binaries, and the > other way around. Whilst most distributions provide some mechanism > to figure out the source build information, those mechanisms vary by > distribution and may not be easy to access from a "foreign" system. > Such mixing is expected with containers, flatpaks, snaps, Python > binary wheels, anaconda packages, and quite often when somebody > compiles a binary and puts it up on the web for other people to > download. 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
