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

Dmitry V. Levin ldv at altlinux.org
Sun Feb 21 18:24:42 UTC 2021


On Sun, Feb 21, 2021 at 10:49:03AM -0500, Neal Gompa wrote:
[...]
> 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. :(

Why should making debugedit either a part of elfutils or a separate
project be any more painful for non-Linux systems?

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

Sorry, what do you mean by "elfutils license"?

Currently, debugedit.c is GPLv2+, hashtab.[ch] are LGPLv2+, and both
libelf and libdw used by debugedit are (GPLv2+ or LGPLv3+).

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

On the contrary, I believe all potential debugedit contributors are
perfectly fine with email workflow used e.g. in elfutils.

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

I don't think the choice of hosting is important at this stage of
discussion, but you're well aware that github is out of the consideration
for the reason you mentioned above.


-- 
ldv


More information about the Rpm-ecosystem mailing list