[arch-dev-public] [RFC] Debug packages and debuginfod

[Morten Linderud]

    Give me cake, or give me debug symbols.
        - Some comedian, probably.

Yo!

For quite a few years people has wanted debug packages, but there has never
really been any progress towards them. Pacman got support almost 10 years ago,
and Allan wrote a POC for dbscripts in 2015[1].

In recent years this has largely been a discussion how large such a repository
would become, and how to distribute it. But since we don't have any numbers
things have more or less stalled with things being discussed, but never worked
on. Dropping an imaginary 100 GB on some poor mirror hosts doesn't seem quite
right. 

However, things has been been progressing for the better when it comes to the
distribution of debug symbols that can hopefully make this entire process easier
for us. debuginfod has been introduced into elfutils which allows a standardized
API for fetching remote debug symbols [2]. Eli and I have have been chatting
a little with upstream since February to ensure we could get our package
format supported. This was fairly straight forward with an example package
from us and things have been working nicely.

Patches in elfutils:
https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=499129e77aa88b94756bd6c8d50347721689065c
https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=0245c6ed65a80bceb105317525f0cf38bf27b623
https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=ad09e791320d13149854ce7a0529842ea0d41a3d

We have been distributing debuginfod since 0.178-1 and debuginfod support came
to gdb with the 10.1 release, which is why I'm picking up on this now :)

We did some testing with the debuginfod support with Stapelberg during the
summer, and it works fairly well [3]. Eli has also started writing up the
support for splitting out the debug packages into a separate pool [4]. I have
since merged some of Elis dbscripts patches to the POC git migration server to
test things.

The idea is to allow uploads of debug packages to repos.a.o into a separate
package pool, have a public reachable debuginfod and then consider if we
want/need debug package distribution. We can then check the new mirror
requirements, and give a clear heads up to any potential mirror admin while
providing debug packages. I think this is a reasonable compromise for everyone.
OpenSUSE already has one such server as an example [5].

There isn't any one way we have to progress on this, but my proposed timeline is
as follows:

- Add a debuginfod role to the infrastructure repository.
- Test and deploy the dbscripts support for debug packages.
- Add support to devtools for uploading debug packages.
- Announce debuginfod support.
- Discuss how to distribute the packages.

I anticipate we can start a new discussion for the last point as I think there
is some issues we should think about in terms of archiving debug packages and so
on.

Is there any questions, concerns or suggestions for this proposed
implementation?

If anyone is interested trying out debug packages and debuginfod, on the POC git
migration server, please do poke me!

-- 
Morten Linderud
PGP: 9C02FF419FECBE16

[1]: https://lists.archlinux.org/pipermail/arch-projects/2015-August/004301.html
[2]: https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server/
[3]: https://twitter.com/zekjur/status/1268626664814247939
[4]: https://github.com/eli-schwartz/dbscripts/commits/wip/debug
[5]: https://debuginfod.opensuse.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20201123/2fbfda8f/attachment.sig>