The quickcheck crate has released version 1.0 a while back.

Looking at the git history, it seems the changes between 0.9.3
and 1.0.0 were fairly minor, so in most cases I suspect this can
be addressed by patching dependencies.


This new version itself depends on:

 - rand 0.8 (unstable only has version 0.7.3-3)

In general when looking at dependency bumps, I often use the blame feature on 
github
and similar sites (which IME are far easier to use than the command line git 
blame) to
see if any other changes were made at the same time as the dependency bump 
upstream.

The changes for rand 0.8 look relatively small and easy to back out to me.

https://github.com/BurntSushi/quickcheck/commit/319145dfb9e8e1f2d405276bb88ac03b7f56aca3

I think it probably makes sense to do a rust-rand 0.8.x transition at some 
point in the not too
distant future , but I would personally wait until other transitions such as 
futures/tokio
and the rust gtk stack are over.

 - env_logger 0.8.2 (unstable already has 0.9.0-1)

rust-quickcheck was already patched in Unstable by a NMU to use env_logger 0.9, 
so I can't see
this being a problem.

librust-im-rc+quickcheck-dev 15.0.0-1 depends on librust-quickcheck-0.9+default-dev, librust-petgraph+all-dev 0.5.0-1 depends on librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev, librust-petgraph+quickcheck-dev 0.5.0-1 depends on librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev,

It doesn't look like these feature packages have any reverse dependencies, so 
worst
case, they could be dropped if they can't reasonablly be fixed.
(I suspect they will be easy enough to fix though)

Source packages in unstable whose autopkgtests are triggered by rust-quickcheck:

rust packages in Debian generally have "skip if uninstallable" set on their 
autopkgtests.
So these aren't directly blockers (though it would be nice to fix them if 
possible).

This might be a kind of messy transition, so i'm opening this ticket to
keep track of it.

It doesn't look that bad to me.

Reply via email to