[Pkg-rust-maintainers] debcargo update handling alternative build depends

[Vasudev Kamath]

Ximin Luo <infinity0 at debian.org> writes:
>
> Thanks for getting to the root of this issue! That sounded like a
> tricky one to debug.

Actually I got it quickly once I went through build log. There was first
failure due to missing alternative build depends which triggered
installation dose and again trying to resolve. I assume this is the
aspcud resolver mentioned in sbuild man page. And this resolver failed
with message saying it can't find dh-cargo:amd64.


>
> A very simple solution would be to reverse the list so the highest
> version appears first, but this wouldn't work well for ranges whose
> upper limit doesn't yet exist as a real crate, nor for >-only ranges
> that don't have an upper limit, so I think we have to reject this
> simple solution.

Yes, besides this build failure occurred in our specific case because we
didn't had librust-rand-0.3+default-dev where as
librust-rand-0.4+default-dev but in real archive if first one is present
then build succeeds. And if last one of alternative dependency is
non-existent then our simple solution will break.

But OTOH its just upto maintainer to package
librust-rand-0.3+default-dev before he uploads this package. The whole
problem is rooted at our mixing of cargo tree in our test script. Which
resolves to a correct version on crates.io.


> I think it would be preferable to keep the list of alternatives, but
> do the resolving as you say and use that version as the first one in
> the list of alternatives. It would be good to be able to override this
> "first version" in the config file as well.

I see 2 approaches.

1. Keep alternative build depends and make sure to warn maintainer about
   making sure first of alternative build dependency is exist/uploaded to
   archive before uploading this package. 
2. Use cargo API to resolve the version to appropriate crate.

1 actually offloads some complexity from debcargo and puts that weight
onto maintainers shoulder. In 1 maintainer can also override
build-depends via override file.

2 though seems straight forward might not be elegant solution. If there
is a newer version of dependency is uploaded to crates.io a second run
of debcargo to update the package will create new dependency, though
older one might still have worked.

Our solution should be such that we don't complicate debcargo and we are
not going to create a burden for maintainer. I'm open for suggestions :-).

>
> Did your build succeed?

As said earlier on IRC it did not as crates-io crate was allowed to
fail. Any reason why you allowed it to fail?. I tried to debug but did
not get enough time.

Now that I've uploaded cargo 0.25.0 I will look into crates-io failure
case.

Cheers,

--
Vasudev