[Pkg-rust-maintainers] Bug#1013729: rust-zbus: Please upgrade to version 2.2.0

[Reinhard Tartler]

On 7/2/22 15:52, Peter Michael Green wrote:
> There seems to be a group of 4 closely related packages, zbus, zbus-macros, zvariant and zvariant-derive which
> should probably be upgraded in lockstep.
> 
> 2.x (3.x for zvariant) is a semver break, so reverse dependencies need to be investigated.
> 
> rust-ashpd - fixed upstream, upstream fix involves a semver bump but there are no rdeps.
> rust-libslirp - no upstream fix, no rdeps, but does produce a binary crate. Popcon is low, but we did get a bug report from a real user, so it's not totally unused.
> rust-secret-service - no upstream fix, no rdeps, no binarys
> squeekboard - no upstream fix, seems to be used by the "phosh" desktop.
> 
> I can't find any upstream changelog, but I did a quick attempt at bumping the dependencies in libslirp-helper and came to the conclusion it would be a non-trivial porting job.
> 

According to https://crates.io/crates/libslirp/4.3.0/dependencies zvariant is mentioned as an optional dependency. Can we take the option to avoid the dependency, maybe at the expense of unit tests?

> There is also the problem that squeekboard is currently failing to build on ppc64el due to what may or may not
> be a rust bug ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013273 )

ppc64el is a tier 2 architecture. Maybe we can stop building in it on ppc64el for the time being?

> 
> The other option would be to introduce seperate packages for the old versions of the crates, so that the
> main packages could be upgraded to the new semver, we try to avoid such duplication if possible
> though and I do not intend to introduce packages myself.
> 
> I belive hntourne was also showing an interest in zbus, putting him in cc.

Do we want to update zbus, zbus-macros, zvariant and zvariant-derive in experimental to ease with the porting effort?

-rt