Users (and developers) don't just want to run an executable, they also like to know that it runs efficiently, that it doesn't use unnecessary resources and if it crashes and burns they want to collect the pieces and inspect what went wrong. So a package should also provide the user with a means to easily profile, trace and debug what is running on their system. This means a distro should also package symbols, debuginfo and sources for easy/automatic installation. With different distros and different versions of distro packages running next to each other in containers we need some standard conventions to identify executables (build-id) and match and fetch the needed symbols, debuginfo and sources to help the user profile, trace and debug any binary they find on their system.
We will go briefly over differently tools for shared library abi inspection, tracing, debugging, profiling and post-mortem crash analysis. What extra information such tools need, like CFI/backtrace, symbols, gnu_debugdata, debuginfo and sources. Then we will discuss the tools that are used on Fedora to extract and package the extra information. How build-ids are used as a means to find/match the information. So the user/developer can know exactly which version of a library was actually running when the core file was created for example. And identify some deficiencies in the current packaging. It is impossible to install both the 32bit and 64bit version of the debuginfo for example. What extra challenges there are when you might be running different versions of a package in different containers. And some suggestions on tools and conventions that distro packages can adopt to make all this easier for the user and tools. At the end it would be nice to have a discussion how other distros deal with some of these challenges. How distros/packagers can coordinate on making this information (a symbol/debuginfo server) available cross distros and how/if to extend these ideas to non-native ELF/DWARF executables.
Speakers: Mark Wielaard