[Rpm-ecosystem] rpm debugedit as a separate project?

[Mark Wielaard]

Hi all,

rpm debugedit has grown from a quick hack that simply listed/replaced
some files/strings to an almost full blown DWARF reader/writer. It is
now also used outside rpm(build). Debian packages it separately and
Flatpak builder has an embedded copy it uses to post-process debuginfo.

It is currently not always easy to update because the people who
contribute to debugedit are often not regular rpm contributors. And the
release cycle of rpm doesn't always match up with the release cycle of
the GNU toolchain. So it sometimes needs a release at a different time
than rpm gets released.

There have been some requests to have it moved from rpm to elfutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=27351
But I think it would be simpler to have it be its own project, so it
isn't tied to another projects release schedule and processes.

So my proposal is to:

- Create a debugedit project on sourceware, so it is close to binutils,
  from which it sometimes steals code, elfutils on which it relies for
  libelf/libdw, and dwz which is a similar, but completely different
  DWARF processor. Most people currently contributing to rpm debugedit
  should already have an account there.

- Import tools/debugedit.c tools/hashtab.c tools/hashtab.h and
  tests/debugedit.at from rpm. Add a minimal build using autoconf and
  autotest around this. Update the hashtab files from libiberty,
  check debugedit (and sepdebugcrc checkm see below) for updates
  which came in from binutils. Note, it also has a popt dependency.

- Setup buildbot using builder.wildebeest.org/buildbot which has
  support for debian/fedora/centos, armhf, i386, x86_64, aarch64,
  s390x, ppc64 and ppc64le.

- Provide patches for rpm to have some kind of --with-system-debugedit
  configure flag so it won't build and install its own debugedit
  but picks up an installed debugedit on the system.

- Provide patches for flatpak-builder to use debugedit like it already
  uses eu_elfcompress and eu_strip, instead of calling
  builder_get_debuginfo_file_references.

- Setup the buildbot so it runs the rpm and flatpak-builder testsuites
  against debugedit to make sure we keep compatibility.

  This should in theory be easy because both have testsuites that
  should be zero-fail. But in practice I never got the flatpak-builder
  tests all green because I don't understand what it is doing with
  gpg-agent. And I always trip over the usage of fakechroot in the rpm
  testsuite, on some setups it seems fakechroot is just totally broken?

An open question is for how long rpm and flatpak-builder want to keep
their internal implementation. And if so, how we keep them in sync. Or
if we simply decide that once debugedit is ready as separate project
the next release of rpm and flatpak-builder will simply require
debugedit as external executable.

Another question is whether the separate debugedit project should also
adopt some of the other related tools like sepdebugcrcfix, elfdeps and
maybe scripts/find-debuginfo.sh? sepdebugcrcfix and elfdeps seem easy
to adopt. find-debuginfo.sh is very tightly linked to how rpm builds
debuginfo/sources subpackages. But maybe it could be made a little bit
more generic? But if so, keeping compatibility might be tricky.

I don't think a separate debugedit project needs much maintenance once
setup. But there are a couple of items to work on. In particular
support for DWARF5 as emitted by alternative compilers and handling
Split Dwarf.

Comments and feedback more than welcome.

Cheers,

Mark