Re: Uncoordinated upload of the rustified librsvg
I agree with most of you message, specially that we cannot keep using
librsvg-in-c forever, but a couple of things:
2018-11-06 06:02 Josh Triplett:
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.
I don't know for sure, but I think that the real reason why it was not
uploaded to unstable until less than a week ago was not so much about
impact or being disruptive on its rev-deps, but because rustc was not
available in a few stable-release architectures [1,2,3], and not be very
stable in others [4,5] until a few days ago .
So if that interpretation is true, librsvg --in Debian-- could move on
to its -rust implementation not because it was sufficiently stable or
mature in itself, but thanks in good part to Adrian's effort and people
who care "about the 1%" (taking the expression from another message in
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.
Perhaps in the future, but that's not really necessary today. I am
running systems without LLVM or Rust support and they do their job just
fine. Rust(*) is not necessary for anything except Firefox, Thunderbird
and now librsvg; and LLVM only for a few things, but the areas where
it's needed are not near universal, and not having it available it's
less than 10% of the impact of not having librsvg.
(*) BTW, I don't dislike Rust per se, in fact I was trying to learn it
and started to read the book and create some test programs lately.
[...] 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.)
That's not really true either, I needed to build a librsvg-in-c to be
able to build emacs, so it's already affecting some ports.
Manuel A. Fernandez Montecelo <firstname.lastname@example.org>