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