Debian, Rust, and librsvg

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

Debian supports many architectures and, even for those it does not officially support, there are Debian ports that try to fill in the gap. For most user applications, it is mostly a matter of getting GCC up and running for the architecture in question, then building all of the different packages that Debian provides. But for packages that need to be built with LLVM—applications or libraries that use Rust, for example—that simple recipe becomes more complicated. How much the lack of Rust support for an unofficial architecture should hold back the rest of the distribution was the subject of a somewhat acrimonious discussion recently.

The issue came up on the debian-devel mailing list when John Paul Adrian Glaubitz complained about the upload of a new version of librsvg to unstable. Librsvg is used to render Scalable Vector Graphics (SVG) images; the project has recently been switching some of its code from C to Rust, presumably for the memory safety offered by Rust. Glaubitz said that the new "Rust-ified" library had been uploaded with no warning when the package maintainer "knows very well that this particular package has a huge number of reverse dependencies and would cause a lot of problems with non-Rust targets now". The reverse dependencies are the packages that rely on librsvg in this case.

Glaubitz noted that he has put a lot of effort into getting Rust working for various unofficial architectures. In fact, on November 2, he had announced that four new architectures now had Rust support, which meant that all of those that are officially released by Debian are covered. That brought the number of Debian architectures with Rust support to 14. His goal, it would seem, is to get Rust running on all of the ports architectures eventually. So he was unhappy that the new upload has made his work on Debian ports "harder with all the manual work required for maintaining librsvg on the non-Rust targets now". He concluded with a final shot:

I'm really annoyed and disappointed by this move and feel really let down by this behavior. No heads up, no coordination, no nothing. Is that seriously the way we want to work together?

Though never mentioned by name, apparently Jeremy Bicha was the target of Glaubitz's ire. Bicha responded by noting that there was some coordination on the upload, as documented in a Debian bug report. That coordination was aimed at the supported architectures, however, and was "with the Release Team and not with whoever maintains ports". Part of the problem, evidently, is that Bicha is not clear on how one might even coordinate with the ports maintainers; ports is not exactly in the Debian mainstream, he said:

I guess to some degree I consider the ports to be as much or as little a part of Debian as nonfree is. Officially, they aren't part of a strict definition of Debian, but they are part of the broader Debian ecosystem.

Adam Borowski's call for a revert of the upload was not well-received. Ben Hutchings said that Debian bases its releases and their contents on the architectures that will be included. "We do not allow Debian ports to hold back changes in unstable." Bicha pointed out that the reversion would have a rather unreasonable outcome: "It sounds to me like you're saying that to fix librsvg being out of date on 11 arches, we need to make it out of date on every architecture."

Bicha continued that he did not mean to upset Glaubitz with the upload. "It honestly didn't occur to me that I ought to talk to ports maintainers before uploading packages that won't build on ports." Beyond that, the new version of librsvg spent months in the experimental repository without complaint. He also noted that the announcement did not come with a warning:

Or maybe you could have said "Rust is now available on all release architectures, but please talk to us before uploading a rustified library." While today's upload was apparently a surprise, I don't think it should have been a surprise that this upload was coming.

The announcement of Rust support on more architectures and, importantly, all of the release architectures is what allowed Bicha to upload the new version of librsvg, however. So Glaubitz feels like his work to make that happen has been used against him. He rejected Bicha's suggestion:

Did you seriously expect me to write "Hey, I fixed Rust on the remaining release architectures but please don't use this as an excuse to hurt my other work!"? I rather think that this should be dictated by common sense and mutual respect for the work of fellow Debian members.

A suggestion made by Samuel Thibault may provide a temporary way to move forward. He suggested that the older version of librsvg be given a different source package name (others suggested "librsvg-c") but build the same binaries as librsvg for architectures that lack Rust support. That will work, but will leave those architectures with an outdated (and unsupported) version of librsvg. Bicha asked for a volunteer to step up to maintain librsvg-c, though Manuel A. Fernandez Montecelo gave a long explanation of why he thought the Debian GNOME team (of which Bicha is a member) should maintain librsvg-c alongside librsvg.

But the aggressive tone of Glaubitz's messages (including this followup) was not particularly helpful. He seems to have a rather one-sided view of respect and communication between Debian participants but also feels that his work in getting Rust on more architectures was not really appreciated and acknowledged by the rest of the project. Various project members tried to rectify that in a sub-thread, while also noting that his messages were unnecessarily harsh and off-putting.

Josh Triplett said that he didn't really see more coordination leading to a different technical outcome; other libraries and applications will be using Rust over time, so architectures that don't support it are going to get left further behind. Librsvg is simply the first to go down this path for Debian (though recent versions of both Firefox and Thunderbird also use Rust):

I think it's reasonable for the *first* such library being uploaded to wait a little while to coordinate, which it did. I don't, however, think it's reasonable to wait indefinitely. If even more coordination had taken place than what already did, what would have been the expected outcome? I think the correct answer *was* "it works on the release architectures", precisely because if non-release architectures need to keep an outdated version while working on porting efforts, they'll automatically do so, and that shouldn't impede those architectures too much as long as other packages don't start depending specifically on functionality from the new librsvg. (And if packages do start having such dependencies, they'll get held back too.)

He asked what kind of help was needed in order to get LLVM and Rust support onto the remaining architectures. Glaubitz replied with a sizable number of complaints about Rust and its upstream; he is also skeptical of the security claims that are made for the language. He did point to three reviews needed for LLVM and to a bug in Rust that needed to be fixed, but he couldn't resist complaining about the stability of the Rust language as well as its six-week release cycle. According to Triplett, though, most of the Rust stability problems that are being complained about boil down to running Rust on unsupported and, critically, untested architectures. He pointed to the Rust platform-support page and suggested that platforms not in tier 2 are not going to be well supported.

In yet another lengthy reply, Glaubitz continued to complain about Rust. In fact, he said: "[...] I think it's a bad idea to use Rust code in a core component like librsvg". As Triplett pointed out, though, Debian cannot control what languages are used by upstream projects. Beyond that, he is not seeing any real actionable call for assistance by Glaubitz or others working on Debian ports.

In the end, it is not entirely clear what Glaubitz wants—at least what he wants that is within the realm of possibility. Rust may irritate him, but he can't stand in the way of projects that want to use it, even if it means that there are some less popular architectures that cannot support them. His tone seems to discourage exactly what he might like to see happen (Rust on the rest of the ports architectures). It is understandable that he is unhappy that his work on getting Rust working for more architectures enabled librsvg to move forward for most of Debian—and all of the official parts of the distribution. The ports that do not yet support Rust are going to need to make that happen or be left behind it would seem.