state of the rust ecosystem (and particularly rust-cbindgen) in Debian (was: Requesting backport of cbindgen > 0.10.0 to buster)

[peter green <plugwash@p10link.net>]

(note: these are my observations as a maintainer of a derivative)

> The rust ecosystem in Debian
> recently had (and I expect still has) trouble to properly migrate to
> testing 
>     
    Indeed there are still issues, most notablly IMO that firefox-esr's
    build-dependencies have been unsatisfiable in testing for over 7
    months because rust-cbindgen has not been able to migrate to
    testing.

> and is missing a *demonstrated* sane dependency and versioning
> scheme (in the context of how Debian is working *at this moment* in time).
>     
    A big difference with rust and most other languages in this regard
    seems to be that rust dependencies, both upstream and as source and
    binary dependencies in Debian are typically pessimistic.
    
    Contrast this with most other languages in Debian, for C/C++ stuff
    the binary dependencies are typically somewhat pessimistic, but the
    source dependencies are typically optimistic. For most interpreted
    languages, both the source and binary dependencies are optimistic.
    
    Another factor is that the rust packages make heavy use of versioned
    provides. Unfortunately while apt and britney seem to handle these
    fine the packages.debian.org web interface and the autoremovals
    system do not (or at least did not last time I looked). The former
    makes understanding rust dependencies difficult. The latter made
    filing rc bugs against rust packages with broken dependencies in
    testing fairly fruitless.
    
    Yet another issue is that it took "rust-compiler-builtins" a long
    time to get through new, this blocked a lot of rust packages from
    transitioning to testing for a long time, which in turn blocked
    migration of new versions of a number of fairly important packages.
    
    The result of all this was a massively snarled up dependency tangle
    preventing stuff migrating to testing.
    
    It seems that in the end Paul Gevers (elbrus) decided to just do a
    mass removal of rust stuff from testing, this did un-jam some stuff
    but it also excarbated the autopkgtest issues because a test that is
    already failing in testing is not a blocker for a new version to
    migrate, but once a package is out of testing the autopkgtest will
    stop it re-entering.
    
    As far as I can tell, right now rust-cbindgen's re-entry to testing
    seems to be blocked by autopkgtest failures in the following source
    packages
    
    rust-libc ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955997
    )
    rust-compiler-builtins
    rust-atty
    rust-unicode-normalization
    rust-autocfg
    rust-cfg-if (this one has actually previously passed)
    rust-no-panic
    rust-failure-derive (this one has actually previously passed)
    rust-rustc-demangle
    rust-uuid
    rust-goblin (
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947711 )
    rust-futures
    rust-cc
    rust-pkg-config
    rust-futures
    rust-backtrace-sys
    
    
    And by uninstallable featureset packages in the following source
    packages
    
    rust-unicode-width
    
    And by the requirement for source-only uploads in the following
    packages.
    
    rust-compiler-builtins
    rust-goblin
    rust-adler32
    
    And by FTBFS bugs in the following source packages
    
    rust-core-arch (
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952228 )
    
    And by other RC bugs in the following packages
    
    rust-spin ( Moritz thinks the package should not be in testing
    because it's abandoned upstream
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946921 )