Re: Uncoordinated upload of the rustified librsvg
John Paul Adrian Glaubitz wrote:
> >> Why would I need to communicate that? <snip/>
> > Because coordination needs involvement from all
>
> If the maintainer of a package doesn't understand which reverse
> dependencies his package has, he shouldn't be the maintainer of
> his package.
This is not a situation that needs such further escalations and
hyperbole.
The problem here is *not* simply knowing the reverse-dependencies; I
feel certain the maintainer of librsvg is well aware of what depends on
librsvg. And conversely, I'm sure that the maintainers of packages
depending on librsvg are aware of that dependency as well.
librsvg has rewritten substantial fractions of its code upstream in
Rust. It won't be the last such library or package to do so. librsvg sat
in experimental for months, precisely *because* the maintainer knew that
such a change could potentially be disruptive, and wanted to properly
integrate it into Debian. But the new upstream version fundamentally
depends on Rust.
Running old versions of a library is not a viable long-term strategy.
Attempting to find alternatives written in C is not a viable long-term
strategy either; that's running in the wrong direction. Ultimately, the
new version will need uploading to Debian, and an architecture that
wants to run a full desktop, or for that matter a server or embedded
environment, will need to have LLVM support and Rust support.
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.)
Approaching the problem from a different angle: what help is needed
getting a viable LLVM and Rust development environment for more
architectures? Speaking with an upstream Rust hat on in addition to a
Debian hat: what could Rust do to make life easier for porters? And what
could Debian's *considerable* expertise in porting do to make that more
sustainable upstream? (As an example, it might help if upstream Rust
folks had access to machines for more architectures, though that's a
side issue for having an LLVM port in the first place.)
Reply to: