package: debhelper


Hi Niels,

As noted on irc today, it would be nice if debhelper could add support for
handling versioned dependencies between packages in a way that would allow
arch: all binNMUs.

The current practice of using

Package: arch-any
Depends: arch-all (= ${source:Version})

doesn't work if arch-all is binNMUed (because then the version is no longer
the same as the source version).

See also
https://lintian.debian.org/tags/maybe-not-arch-all-binnmuable.html

Having versioned dependencies between arch-all and arch-any is already broken:

Package: arch-all
Depends: arch-any (= ${binary:Version})

Would fail if arch-any is binNMUed.

See
https://lintian.debian.org/tags/not-binnmuable-all-depends-any.html



Some possible ways to handle versioned dependencies that don't have these
issues:

- Add these depends:

Depends: arch_any (>= ${source:Version})

or

Depends: arch_any (>= ${source:Version}),
  arch_any (<< ${source:Version}.1~)

This is suggested by lintian, but it hard-codes the assumptions about binNMU
versioning. Also this is wrong when there is an NMU versioned +nmu1, or a
+deb9u1 stable update.

- Create a virtual package and use that as a dependency:

Package: arch-all
Version: 1.0-1+b1
Provides: somevirtualpackage

Package: arch-any
Depends: somevirtualpackage

In this case, somevirtualpackage should be unique for every binary package and
source version, but the same for different versions of the same binary package
built from the same source. It could be something like
virtual-arch-all-1.0-1

- Using versioned provides

Package: some-package
Version: 1.0-1+b1
Provides: some-package (= 1.0-1)

I think this would be a bad idea, because the binNMU is usually done for a
reason, so the new package shouldn't pretend to be the old one, because they
will be different.


Obviously, there might be other ways to handle this.


It would be nice if debhelper could implement a standard way to deal with
these dependencies (whatever way is considered to be the best). However, I
don't know if this can be done with a simple substvar. It probably might need
some kind of macro:

Package: arch-all
Depends: VERSIONED_DEPENDS(arch-any)

In this case, debhelper would need to expand "VERSIONED_DEPENDS(arch-any)" to
the correct dependency (obviously the syntax could be different).



If the handling of versioned dependencies between binaries of the same source
could be handled like this, the substvar ${source:Version} should probably go
away in a future debhelper version, to prevent creating versioned dependencies
that are wrong when arch: all binNMUs are used.



Thanks,

Ivo

Hi Niels,

[...]

I created a proof of concept implementation of this idea in the attached
patches. They are also available as a git branch on salsa:
https://salsa.debian.org/ivodd/debhelper/tree/provide-deps

0001-Dh_Lib.pm-add-get_version-and-get_source_version.patch creates the
'get_source_version' function needed by the next patch. If this patch is
merged, the use of the 'side effect' of the isnative function to get the
version of the package could be discouraged in the future.

0002-Add-PkgSourceVersion-substvars.patch creates the substvars. The naming of
the variables and the virtual package are just examples, they could obviously
be changed. Note that I don't think the exact name of the virtual package
that is generated should be considered as a stable API that is used by other
tools to generate the same name.

0003-Example-usage-of-PkgSourceVersion-substvars.patch gives an example of how
they could be used. This patch is just an example and should not be merged.

Using these variables would help to create strict dependencies between
binaries from the same source package, which are still satisfied after a
binNMU. This concept could possible be extended to allow packages from other
source package to use these dependencies as well, but that's a possible future
improvement.

Thanks,

Ivo