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

On Wed, Aug 12, 2026, at 03:48, Yves-Alexis Perez wrote:
> On Tue, 2026-08-11 at 21:54 -0700, Brian Tarricone wrote:
>> On Fri, Jul 31, 2026, at 08:31, Yves-Alexis Perez wrote:
>>
>> * 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.

Debian seems to already do this, though.  For example, the `rand` crate has:

librust-rand-0.8-dev/testing 0.8.6+dfsg-1 amd64
librust-rand-dev/testing 0.10.2+dfsg-1 amd64

It looks like the convention is that the latest "major" version gets a package name with no version number in it, and older ones get the "major" version (major.minor for 0.y, that is) in the package name.

In the past few hours I've apparently volunteered to start maintaining gtk3-rs (and someone from the GNOME Rust team who responded on Matrix is ok with it).  First on my list is to get it building against the current versions of some of those old dependencies that `cargo debstatus` flagged, so that could be one issue that doesn't end up needing to be resolved.

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

Ah, sorry... re-reading that paragraph, it sounds very hard to follow.  Basically I'm just reiterating what I said above in this email: if Debian only has a package for foobar 0.5 (librust-foobar-dev), but xfwl4 requires foobar 0.4 or 0.6, it seems there's a way to package all the incompatible variants in Debian (e.g. by adding librust-foobar-0.4-dev as a separate package).

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

Fair point!

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

My expectation would be that smithay will have some stable releases we can depend on well before Xorg is dropped from Debian :)  Maybe xfwl4 won't make it into forky, but I'd be very surprised if things weren't in shape in time for duke.

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

Agreed; if packaging from a git rev isn't allowed by policy (or just isn't feasible with the existing tools, and no one has the time to change that), it probably makes sense to hold off on doing any of this packaging until smithay does have a stable release we can depend on.

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

Sure thing!  I'm curious to hear the outcome.

Cheers,
Brian
_______________________________________________
Xfce4-dev mailing list
[email protected]
https://mail.xfce.org/mailman/listinfo/xfce4-dev