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

[Dmitry V. Levin]

Hi,

On Fri, Feb 19, 2021 at 09:23:58PM +0100, 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.

The advantage of building debugedit along with elfutils is that all
workarounds required to build with older elfutils could be removed, e.g.
this wouldn't be needed:

/* Unfortunately strtab manipulation functions were only officially added
   to elfutils libdw in 0.167.  Before that there were internal unsupported
   ebl variants.  While libebl.h isn't supported we'll try to use it anyway
   if the elfutils we build against is too old.  */

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

Yes, sourceware should be fine.

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

The main obstacle is that tools/debugedit.c currently depends on rpm:

$ git grep -h rpm tools/debugedit.c
#include <rpm/rpmio.h>
#include <rpm/rpmpgp.h>
      if (rpmDigestLength(algorithm) == build_id_size)
  ctx = rpmDigestInit(algorithm, 0);
    rpmDigestUpdate(ctx, build_id_seed, strlen (build_id_seed));
	rpmDigestUpdate(ctx, x.d_buf, x.d_size);
	  rpmDigestUpdate(ctx, x.d_buf, x.d_size);
	      rpmDigestUpdate(ctx, d->d_buf, d->d_size);
  rpmDigestFinal(ctx, &digest, &len, 0);


-- 
ldv