On Fri, 2021-05-14 at 14:41:32 +0100, Luca Boccassi wrote:
> On Fri, 2021-05-14 at 12:41 +0200, Guillem Jover wrote:
> > On Sat, 2021-04-10 at 13:38:31 +0100, Luca Boccassi wrote:
> > > On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote:
> > > > After an initial discussion [0], recently we have been working on a new
> > > > specification [0] to encode rich package-level metadata inside ELF
> > > > objects, so that it can be included automatically in generated coredump
> > > > files. The prototype to parse this in systemd-coredump and store the
> > > > information in systemd-journal is ready for testing and merged
> > > > upstream. We are now seeking further comments/opinions/suggestions, as
> > > > we have a few months before the next release and thus there's plenty of
> > > > time to make incompatible changes to the format and implementation, if
> > > > required.
> >
> > I've skimmed over the discussion at [0], and while having this data
> > seems like it might be "nice", I've to agree with the comments there
> > voicing that there does not really seem to be an actual need and the
> > overhead and additional work do not seem worth it, TBH, at least
> > in the Debian context.
> Hi Guillem, thanks for having a look, much appreciated!
>
> Just to clarify, the need is there - this is not an experimental
> exercise, but it is borne out of an actual need, and it is
> undergoing testing right now before deployment in a large scale
> production infrastructure.
> Not _everybody_ will need it, and not everywhere - that's absolutely
> fair, and discussions on whether the ovearhead is worth it for
> something that is not universally needed, but only in certain use
> cases, is perfectly reasonable and welcome. I know Zbigniew is going to
> try and get some raw numbers on the kind of overhead we are talking
> about, that will hopefully help frame the discussion with more
> precision.
Sorry, I think I expressed myself sloppily. My impression is not
that there's no need behind this, but that there's no need for this
specific implementation at least in the Debian context, as I think
the information should be already available by other means.
Also when I mentioned overhead here, it was more about packaging and
integration work than say actual size increase, even though that might
have an adverse effect on .udeb's for example, and perhaps a
non-insignificant one on .deb's depending on the amount of objects
included.
> > > > The Fedora Wiki and the systemd.io document have more details, but to
> > > > make a long story short, a new .notes.package section with a JSON
> > > > payload will be included in ELF objects, encoding various package-
> > > > build-time information like distro name, package name,
> > > > etc.
> > > >
> > > > To summarize from the discussion, the main reasons why we believe this
> > > > is useful are as following:
> > > >
> > > > 1) minimal containers: the rpm database is not installed in the
> > > > containers. The information about build-ids needs to be stored
> > > > externally, so package name information is not available immediately,
> > > > but only after offline processing. The new note doesn't depend on the
> > > > rpm db in any way.
> >
> > In the Debian context, the build-ids data is going to be available
> > in the affected executables, and in debug symbols packages and the
> > Packages metaindices listing them, so there's no need for access to
> > any local dpkg database. Given that someone needing to install debug
> > packages will need access to those indices (either with outgoing network
> > access or with a repository mirror), these can be queried at that time.
> > Not to mention that AFAIR the Debian debug symbol servers make it
> > possible to query for specific build-ids.
>
> This is not strictly related to debug packages, though?
That was actually the impression I was getting from reading the refs
though. :) But I'll expand below.
> In fact, on
> systems where this could be of most use you explicitly do _not_ install
> debug packages (or anything at all). Or even if you wanted to, you
> could not - corefiles are not handled inside the container, but
> outside. Even if you wanted to and were allowed to (which for many
> environments it's not the case), you can't install a Debian debug
> package on a CoreOS host or Mariner host or a Flatcar host.
Sure, but precisely dbgsym .deb's are the things that are trivial to
unpack with dpkg-deb (or ar+tar) w/o needing to actually install them.
> > > > 2) handling of a core from a container, where the container and host
> > > > have different distros
> >
> > How each distribution handles debug packages and debug symbols is
> > going to be different, so it seems there will be a need for explicit
> > handling of these, at which point the above mentioned querying can be
> > implemented as well, w/o the need to encode the packaging data inside
> > the executable.
>
> Again, matching to debug symbols is not the main goal here,
