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

Neal Gompa ngompa13 at gmail.com
Sun Feb 21 15:49:03 UTC 2021


On Fri, Feb 19, 2021 at 3:24 PM Mark Wielaard <mark at klomp.org> 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.
>
> 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.

Splitting out from rpm would make the rpm debuginfo support a bit more
painful to support for non-Linux systems, but I guess most don't care
about that. :(

I don't think it'd be a good idea for it to become part of elfutils,
because the elfutils license makes it unshippable for certain
environments (e.g. automotive and medical, where they get panicky
about that sort of thing).

I'm also not comfortable with the idea of having a part of RPM itself
broken out and transferred to a project with subpar contribution
practices. Most of Sourceware still relies on the email workflow for
contribution of fixes and improvements. While you are the main
contributor the last few years (and you don't use GitHub), you are not
the only one, and you are the only one who uses the email workflow. If
Sourceware projects had something like Pagure overlaid on their Git
repos where they could also take pull requests properly, then I'd be
more comfortable with it.

If we really want to split it out, we could just split it out here in
the rpm-software-management GitHub org. That's where popt lives
too[1]. Also, popt is definitely used by more than just RPM stuff, so
I don't know why you noted it as if it's a problem.

Finally, Debian does not use debugedit for their debuginfo generation.
They've got a much simpler process, and they don't generate -dbg or
-dbgsym packages for everything. Notably, security updates usually
don't have it[2]. Debian has it broken out as a subpackage because
there was a proposal years ago to use it, and they didn't.

[1]: https://github.com/rpm-software-management/popt
[2]: https://wiki.debian.org/AutomaticDebugPackages




--
真実はいつも一つ!/ Always, there's only one truth!


More information about the Rpm-ecosystem mailing list