Please raise version number above RPM releases

Please raise version number above RPM releases

[Michał Górny]

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

Re: Please raise version number above RPM releases

[Mark Wielaard]

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

Re: Please raise version number above RPM releases

[Michał Górny]

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

Re: Please raise version number above RPM releases

[Mark Wielaard]

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

Re: Please raise version number above RPM releases

[Michał Górny]

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