Hello, We've been packaging the RPM's debugedit executable as 'debugedit' since 2006. This means that the versions of debugedit packages in Gentoo have corresponded to RPM releases. Now, we'd like to switch to your version. However, the problem is that you've restarted versioning -- at least from our perspective. If we added debugedit-0.3 to Gentoo today, it would be seen as an older version that the 'old' debugedit-4.16.1.3 (i.e. rpm's debugedit). There are hacks around this but they're all particularly ugly. Hence, I'm wondering if it wouldn't be too much of a hassle to you to raise the version number above the current RPM version, i.e. version 5.* or 6.* (if you take rpm5 into consideration, it is pretty dead though). While I do realize the problem's on our end, it's non-trivial to fix because of backwards compatibility requirements we have. And as I said, workarounds are particularly ugly and confusing, so I'd rather avoid them if possible. TIA for your consideration. -- Best regards, Michał Górny
Hi Michał, On Sun, 2021-06-27 at 08:36 +0200, Michał Górny wrote: > We've been packaging the RPM's debugedit executable as 'debugedit' > since 2006. This means that the versions of debugedit packages > in Gentoo have corresponded to RPM releases. > > Now, we'd like to switch to your version. However, the problem is that > you've restarted versioning -- at least from our perspective. If we > added debugedit-0.3 to Gentoo today, it would be seen as an older > version that the 'old' debugedit-4.16.1.3 (i.e. rpm's debugedit). > > There are hacks around this but they're all particularly ugly. Hence, > I'm wondering if it wouldn't be too much of a hassle to you to raise > the version number above the current RPM version, i.e. version 5.* or > 6.* (if you take rpm5 into consideration, it is pretty dead though). > > While I do realize the problem's on our end, it's non-trivial to fix > because of backwards compatibility requirements we have. And as I said, > workarounds are particularly ugly and confusing, so I'd rather avoid > them if possible. Thanks for bringing that up. I think it is fine to make the first official release debugedit 5.0. It will make us look like a really mature project :) Before the first formal release I am doing a few more cleanups, just simple stuff like making sure we are checking all errors, etc. And I would like to make sure there are command line equivalents for the few remaining RPM environment variables used in find-debuginfo: https://sourceware.org/bugzilla/show_bug.cgi?id=27637 There is also one bug reported against Fedora where we fail to produce the main source file in some cases when processing DWARF5: https://bugzilla.redhat.com/show_bug.cgi?id=1966987 For which I have a partial patch, but I am unsure if it is complete. Cheers, Mark
On Fri, 2021-07-02 at 12:36 +0200, Mark Wielaard wrote: > Hi Michał, > > On Sun, 2021-06-27 at 08:36 +0200, Michał Górny wrote: > > We've been packaging the RPM's debugedit executable as 'debugedit' > > since 2006. This means that the versions of debugedit packages > > in Gentoo have corresponded to RPM releases. > > > > Now, we'd like to switch to your version. However, the problem is that > > you've restarted versioning -- at least from our perspective. If we > > added debugedit-0.3 to Gentoo today, it would be seen as an older > > version that the 'old' debugedit-4.16.1.3 (i.e. rpm's debugedit). > > > > There are hacks around this but they're all particularly ugly. Hence, > > I'm wondering if it wouldn't be too much of a hassle to you to raise > > the version number above the current RPM version, i.e. version 5.* or > > 6.* (if you take rpm5 into consideration, it is pretty dead though). > > > > While I do realize the problem's on our end, it's non-trivial to fix > > because of backwards compatibility requirements we have. And as I said, > > workarounds are particularly ugly and confusing, so I'd rather avoid > > them if possible. > > Thanks for bringing that up. I think it is fine to make the first > official release debugedit 5.0. It will make us look like a really > mature project :) Ok, thank you, this will help us a lot. > Before the first formal release I am doing a few more cleanups, just > simple stuff like making sure we are checking all errors, etc. And I > would like to make sure there are command line equivalents for the few > remaining RPM environment variables used in find-debuginfo: > https://sourceware.org/bugzilla/show_bug.cgi?id=27637 > There is also one bug reported against Fedora where we fail to produce > the main source file in some cases when processing DWARF5: > https://bugzilla.redhat.com/show_bug.cgi?id=1966987 > For which I have a partial patch, but I am unsure if it is complete. > I suppose Gentoo will wait for that happen before switching over then. -- Best regards, Michał Górny
Hi Michał,
On Fri, 2021-07-02 at 12:39 +0200, Michał Górny wrote:
> I suppose Gentoo will wait for that happen before switching over
> then.
Forgot to ask, but does gentoo have any patches that could/should be
upstreamed?
Thanks,
Mark
On Fri, 2021-07-02 at 12:41 +0200, Mark Wielaard wrote: > Hi Michał, > > On Fri, 2021-07-02 at 12:39 +0200, Michał Górny wrote: > > I suppose Gentoo will wait for that happen before switching over > > then. > > Forgot to ask, but does gentoo have any patches that could/should be > upstreamed? No, we don't have any patches. Just a few ugly hacks that made it possible to build debugedit without building most of RPM: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/debugedit/debugedit-4.16.1.3.ebuild#n34 I suppose they're irrelevant to the standalone project ;-). -- Best regards, Michał Górny