[Pkg-rust-maintainers] Bug#945560: debcargo autopkgtests are broken for many packages with multiple features

[Daniel Kahn Gillmor]

Package: debcargo
Version: 2.4.0-1

i'm starting to see a pattern of autopkgtest failures for crates with
multiple features.  rust-bindgen and rust-buffered-reader both show this
kind of failure in their autopkgtest suite.
             
In particular, the autopkgtest logs indicate that:

    "/usr/share/cargo/bin/cargo-auto-test $CRATE $VERSION --all-targets
    --features foo" will fail because no matching package named `bar`
    found

and then conversesly:

   "/usr/share/cargo/bin/cargo-auto-test $CRATE $VERSION --all-targets
   --features bar" will fail because no matching package named `foo`
   found
   
infinity0 says: i have general logic in debcargo to add the right
                dependencies and skip the test if they aren't met

but somehow the features running that tests are looking for external deps that they ought not need.
if it was just one package or upstream, i'd say it was most likely a bug
in that package or upstream. But buffereed-reader and bindgen have
different upstreams, and yet they have the same pattern of autopkgtest
failures -- feature foo fails claiming "missing bar" and feature bar
fails claiming "missing foo".

So i think that cargo-auto-test might be common factor.


infinity0 says: i think this might be cargo bug
                https://github.com/rust-lang/cargo/issues/5133 .
                It is cargo itself that wants the presence of those
                extra dev-dependencies even when they are not actually
                needed.
                
                in which case, perhaps we need to work-around it and
                have debcargo actually generate these extra dependencies
                for now in debian/tests/control
                

                in general, cargo requires the presence of optional
                dependencies in the registry even when they are not
                needed for the current command invocation.  this is ok
                when syncing the full registry from crates.io in your
                $HOME but not in debian where the registry is populated
                by the currently-installed packages
                

I've reported this to buffered-reader upstream over here, and they can't
seem to replicate it: https://gitlab.com/sequoia-pgp/sequoia/issues/386,
but infinity0 suggests that this isn't likely to be their probelm
becauseit only affects distros like debian that don't use a full
registry for its distro rust packages.

infinity0 says: for now you can work-around it in your package by
                setting test_is_broken, feel free to file a debcargo
                issue for the more general workaround "have debcargo
                actually generate these extra dependencies for now in
                debian/tests/control"

So that's what this bug report is :)

   --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/20191126/6166d586/attachment.sig>