[Pkg-rust-maintainers] Bug#967954: Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network

[Daniel Kahn Gillmor]

On Thu 2020-10-15 14:51:45 -0400, Daniel Kahn Gillmor wrote:
> On Wed 2020-08-12 13:59:05 +0100, peter green wrote:
>> The proper fix IMO would be to add support for version ranges to
>> dependencies in dpkg
>
> I agree that this seems promising -- we'd then need to have debcargo
> unwind a bunch of its extensive Provides: tags to take advantage of it,
> but that doesn't sound too ugly.  it's possible that introducing ranges
> into build-dependencies would be a problem for dpkg for other reasons
> though.  I'm Cc'ing Guillem here to see whether he has any thoughts on
> the matter.

(sorry for replying to myself here)

Thinking this through further, I think cargo dependency ranges like

   foo = ">=0.4, < 0.6"

do actually already do work in dpkg.  You represent them as:

 Build-Depends:
   librust-foo-dev (>= 0.4),
   librust-foo-dev (<< 0.6)

That would be the easy/simple way to go, so then of course the question
is: why does debcargo use these elaborate Provides: renaming schemes
instead of the simple conjunction described above?

I think the answer is because debcargo wants to be able to explicitly
support a named older version of the library in parallel with the
"latest and greatest" -- a "pinned" line of the package.  so that
librust-foo-dev (maybe version 0.6) can be co-installed with the pinned
librust-foo-0.4-dev (version 0.4.2), and still have that
build-dependency be satisfied.

If there's some other reason, maybe Ximin (in Cc) can clarify it. i
think he understands debcargo's design choices and constraints better
than anyone.

However, this approach isn't going to work on the standard buildd
network, anyway, because the first element of the disjunction generated
by debcargo is likely to be 0.5:

 Build-Depends:
   librust-foo-0.5-dev | librust-foo-0.4-dev

and sbuild will ignore the latter element of the disjunction, and the
package would FTBFS anyway because the BD is uninstallable.  So that
doesn't seem to solve the problem anyway, except in the lucky case where
the highest element of the range happens to also be the one "pinned" in
the current release.

  ---

Looking at other solutions, we also have versioned Provides: fields
available these days.  so if we want to keep rust-foo 0.4 "pinned" in
debian while also tracking the latest-and-greatest rust-foo, then
src:rust-foo-0.4 would produce a librust-foo-0.4-dev binary package
with:

 Provides: librust-foo-dev = 0.4.2-1

then the conjunctive, versioned Depends would be able to figure out how
to satisfy it.

I think this handles the case we're talking about here.

It seems like it could also enable cutting down on the number of
Provides: generated by non-pinned crate packages, once all of the
depending packages had converted to the simpler form.

Are there design constraints or goals that this approach doesn't solve?

Sorry that i'm still (years into the rust debian packagingn process)
trying to get my head around this problem space.  I appreciate folks
bearing with me on this.

(thanks to folks on the #debian-dpkg channel for helping me think this
through).

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20201015/72ee637f/attachment.sig>