dh-elpa detects the `Package-Version' cookie from Elisp source files and
generates Debian version numbers to be used in the substitute variable
${elpa:Depends}.  However there is a small issue that it does not work
well with snapshot version numbers.

For example, say the Elisp source file contains the following line:
,----
| Package-Version: ((foo "1.0.0"))
`----

The generated corresponding Debian version would be
,----
| foo (>= 1.0.0)
`----

This usually works.  However, when the upstream does not have a tag
matching the source version, this would become an issue.  Take the
aforementioned foo as an example: if upstream does not have a tagged
version or the tagged version is lagging behind (e.g. 0.9), we should
usually use a package version combining the source version with a git
snapshot hash, e.g. 1.0.0~git20241101.dedbeef.  Unfortunately, this
version would not satisfy the Debian version requirement because in
Debian "1.0.0~" is less than "1.0.0".

dh-elpa should instead generate snapshot-friendly version number like
,----
| foo (>= 1.0.0~)
`----

Unfortunately, this would require another batch rebuild for all
packages, or this may cause reproducible test issues.

I have made a tentative fix in a
`snapshot-backport-safe-version-handling' branch.  The diff is pretty
minimum and can be see at [1].  PTAL.

[1] https://salsa.debian.org/emacsen-team/dh-elpa/-/compare/master...snapshot-backport-safe-version-handling

Hello,

Here, do you mean ELPA snapshot version numbers or Debian snapshot
version numbers?

In the past when these sorts of issues have arisen, we have concluded
that rather than trying to make dh_elpa too clever, we should just add a
patch in debian/patches to fix the Package-Version header.

Sean Whitton <spwhitton@spwhitton.name> writes:

Here I mean the Debian snapshot version numbers, especially one with
"~", like `1.0.0~git20241207.dedbeaf'.

I don't think that will help, because the Package-Version (e.g. 1.0.0)
will be considered higher than our snapshot version (1.0.0~git%cd.%h)
due to Debian's special handling of "~".  Bumping the version
Package-Version doesn't help as the snapshot version using "~" will
always be considered lower.  Unless we change the version to
`1.0.0git%cd.%h' or `1.0.0+git%cd.%h', that is.

Or maybe I missed something?

Hello,

Oh, in this case we've basically just ignored the package version :)

What is the user impact of the current behaviour?

Hi Sean,

Sean Whitton <spwhitton@spwhitton.name> writes:

I think if we don't append the "~" to the generated version numbers, our
package cannot use "~" based versions like `1.0.0~git%cd.%h', or it may
not meet the requirement.

[ I forgot to mention: I encountered this issue while working on
  emacs-lsp-docker and dap-mode.  dap-mode 0.8 requires `((lsp-docker
  "1.0.0"))', while emacs-lsp-docker does not have any tag.  I uploaded
  lsp-docker with version `1.0.0~git20240806.ce291d0-1', but dap-mode
  piuparts fails as `emacs-lsp-docker (>= 1.0.0)' cannot be met due to
  this restriction.  I have made another upload with version
  `1.0.0git20240806.ce291d0-1' to workaround this, as in case upstream
  tags `1.0.0' I can still use `1.0.0+git%cd.%h' to increase the version
  number. ]

As currently this is not causing any issue for existing packages yet, a
mass rebuild is not necessarily required.  Though I'm afraid that if we
patch dh-elpa with the proposed fix it may make existing packages fail
reproducible build tests as the d/control contents will change.

Another way is to just let apt automatically add "~" to version
handling, which has the benefit of making all version numbers also
backport friendly by default.  But that may be a longer shot :P

Hello,

I understand the issue better now thanks to your example.

We wouldn't want to unconditionally generate >=1.0.0~.  It's useful that
a 1.0.0~git.. version number does not satisfy a standard >=1.0.0
dependency.  It's only when a pre-release is known to work fine that we
would want >=1.0.0~ in ${elpa:Depends}.

There are already snapshot, -git, .cvs etc. version numbers defined.
See `version-to-list'.  Maybe dh_elpa could append a tilde in the
presence of one of those.

Hi Sean,

Sean Whitton <spwhitton@spwhitton.name> writes:

I would expect that if `foo' depends on `(bar "1.0.0")', then bar with
`Package-Version: 1.0.0-git' would also satisfy the requirement, like
saying that bar has added some new interfaces required by foo, and may
(or may not) add more.  Just my 2 cents.

How does Emacs itself handle this kind of version dependencies?

I'm not sure this will help with the dap-mode/emacs-lsp-docker
situation, as the current Package-Version of emacs-lsp-docker doesn't
have a suffix :/

Hello,

Take a look at the documentation of `version-to-list'.  It implies that
1.0.0-git would not satisfy 1.0.0.

But you could patch it in for our packaged version.