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

[Panu Matilainen]

On 2/19/21 10:23 PM, Mark Wielaard wrote:
> 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.

As already stated elsewhere, the rpm developers fully support and 
encourage this, regardless of the exact whereabouts. If it makes more 
sense as a separate project to you, then that's absolutely fine.

> 
> 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.

As for rpm, we'll simply require an external debugedit from the go, ie 
as soon as there is a released standalone debugedit exists.

> 
> 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.

sepdebugcrcfix makes even less sense in rpm if debugedit goes, so yeah 
please adopt that too. find-debuginfo.sh might be tricky, but something 
I would prefer to see moved too - eventually if not at the start.

As for elfdeps, unlike debugedit and sepdebugcrc it's just a simple 
libelf client which walks ELF structures and maps it to fairly 
rpm-specific output (those wacko "()(64bit)" markers only on select 
64bit arches and all) , and has not been any sort of maintenance burden 
from my POV. I see no need to move it anywhere as it is.

> 
> 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.

I have mostly just one: thank you for this initiative!

	- Panu -

> 
> Cheers,
> 
> Mark
> _______________________________________________
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
>