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

[peter green]

(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 )

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20200410/1ecc7c17/attachment.html>