Re: Concerns Regarding the Choice of Rust for the Xfce Wayland Compositor

On Fri, Jul 31, 2026, at 08:31, Yves-Alexis Perez wrote:
>
> There's a really helpful `debstatus` command in cargo which indicates what is
> missing from the distribution, and we're definitely not there yet:
> https://paste.debian.net/hidden/cd97a155
>
> Besides the missing packages, I'm worried about conflicting versions: xfwl4
> seems to require versions older than what's in Debian, for some reason.

Looks like the paste expired, but I just installed and ran it myself.  Let's see... here's where xfwl4 depends on older versions than Debian has:

* rand 0.9 (and its deps): just submitted a smithay PR[0] to get that updated
  to 0.10; I'm sure that will be fine.  xfwl4 also depends directly on 0.9,
  which I'll update shortly.
* pangocairo, pangocairo-sys 0.18: debian has 0.22. Unfortunately this is
  a side-effect of using gtk3-rs; we cannot update past 0.18, so this older
  version needs to be packaged.
* system-deps 6.x, cfg-expr 0.15, target-lexicon 0.12: these are all
  build-deps of stuff in the gtk3-rs stack, which we can't change,
  unfortunately, so these older versions need to be packaged.

Also problematic:

* winit 0.31.0-beta: For some reason smithay decided to update to a beta
  version of winit; hopefully the final release of 0.31.0 will come soon,
  and I assume Debian can update.  If this continues to be a problem,
  Debian can ship xfwl4 with the `winit` feature disabled, which kills
  the dependency, at the expense of being unable to run xfwl4 nested inside
  another Wayland session.  (X11 will still work, as xfwl4 has a dedicated
  nested-x11 backend.)
* wayland-protocols-experimental 20250721.0.1: that feels like a non-semver
  versioning scheme; not sure what their policy is on breaking changes.

Then there are a few crates where xfwl4 depends on something older or newer than what Debian packages; I assume that's a matter of packaging version xfwl4 needs.  For stuff where they're semver-incompatible, I see packages in Debian's archive where older incompatible versions of a package are accommodated by putting the compat version in the package name itself, so that should be doable?

And then beyond that there's a slew of packages that just aren't in Debian at all, so that would be a matter of packaging them, presumably with the existing Debian tools.

> Also smithay (and maybe other crates) doesn't seem to do releases and I'm
> unsure we can put in Debian only the exact version required by xfwl4
> (especially if it's not on crates.io which seems to be the source expected by
> Debian Rust ecosystem).

smithay and smithay-drm-extras should be the only deps that don't do releases; all the rest have releases on crates.io.  I know Debian does sometimes package from git sources (a quick check shows 42 such packages installed on my machine right now), though I get that the current Rust tooling for Debian may not support that, so that could be a blocker.

Someone did ask[1] a few months ago about smithay doing more frequent releases to crates.io, but none of the maintainers responded.  From my experience with them on Matrix, they're a great bunch of people (and are super accepting of contributions), but they don't seem to be too concerned about API/ABI stability at this point in smithay's lifecycle, so maintaining API-stable release branches probably isn't something they'd be too interested in.  "Pin your favorite git rev in Cargo.toml" is a perfectly reasonable approach when considering only the rust/cargo community, but of course causes problems for distro packagers.

Cheers,
Brian

[0] https://github.com/Smithay/smithay/pull/2135
[1] https://github.com/Smithay/smithay/issues/2024