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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, 2026-08-11 at 21:54 -0700, Brian Tarricone wrote:
> On Fri, Jul 31, 2026, at 08:31, Yves-Alexis Perez wrote:

Hi Brian, thanks for the reply and the information.

> > 
> > 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:

Ah yes, sorry.
> 
> * 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.

I don't really think that'll possible, nor scalable, to have multiple versions
of the same packages. I don't think we have (yet?) gtk3-rs in Debian so maybe
we'll not be the only one with issues.

> 
> 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?

To be honest, as I'm not familiar with Rust at all, I have no idea what you
mean here :)
> 
> 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.

Yeah, for that I'm not entirely afraid, but it "just" needs to be done.
> 
> > 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.

Yeah, this is (I think) a Debian Rust position rather than a more general
Debian position. Still, I'm not in a position to make that policy change,
especially considering I have zero experience in Rust or Rust packaging for
now :)
> 
> 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.

I can understand that...

>   "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.

But yeah, that doesn't really work with the distributions models. And I can
see that people find the whole distributions with stable releases outdated,
but I don't really see how that scales. Someone has to ship binaries to (a lot
of) end users and I don't think we have a real alternative yet and I still
think distributions (including Debian) are still useful. But maybe that means
we (Debian) won't have smithay, and thus won't have xfwl4, and when Xorg is
dropped from Debian maybe that means no Xfce at all.

We're not there yet, but if there's resolution in sight for smithay (whether
from upstream policy changes or from Debian/Rust policy change) I'm not sure
it's worth spending time packaging all the other dependencies, and fixing the
other issues.

Still, thanks for the detailed analysis, that'll definitely be helpful when we
discuss things with Debian Rust maintainers :)

Regards,
- -- 
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmp8T20ACgkQ3rYcyPpX
RFvMmQgAiffe7rJD3z5CYM6r41YLwEv9anDaBTNawUjW05XLAV5TcXc+skRUW15k
HtVg7PJsDJvToqNePyWIMHVogcABBBHs5e7e7DBFVMMIYvbsPNxV3YPsrNBt7LQ+
fzhEI3L3igP2FX4LcC0xgF/3M4CFQzgxEQoU37v5WDVuwE7im4NqB9C+5EycazLA
yDC4SuMeJ/wEVQ9QihdIVy5Qvc9uYxvDo6brqJiSHJd/u9NLOYP9Cy3RWVepGEzp
BpCWVNZUp8/RgfYtQdCGkaWo/IWAMspi3Tv+3fxnhY7YxoP/EsP0jefDjR5qeoio
qFlwI/y2pKvt9cOT38Dvq2MtBVsIiA==
=CTnN
-----END PGP SIGNATURE-----
_______________________________________________
Xfce4-dev mailing list
[email protected]
https://mail.xfce.org/mailman/listinfo/xfce4-dev