Re: Uncoordinated upload of the rustified librsvg
Hi,
2018-11-04 01:13 Ben Hutchings:
On Sat, 2018-11-03 at 23:46 +0100, Adam Borowski wrote:
> The maintainer of the package 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. He also knows very well that I am very
> much interested in Debian Ports and a lot of efforts have been invested there.
Perhaps we should quickly upload a revert, using the last good version of
librsvg, before things degrade? Effectively removing librsvg on 11 archs
(not counting non-official ones) stops any GUI there. Including proverbial
fvwm.
librsvg doesn't appear to be a hard dependency for fvwm.
In fact, src:fvwm has a Build-Depends on "librsvg2-dev (>= 2.13.92)",
and the binary package a Depends on librsvg2-2, which are provided by
src:librsvg.
If by "hard dependency" you mean that it can be disabled for a bunch of
arches, sure, it is possible if changes in the dependencies are
implemented.
But then that means that a significant percent of the archive, say, even
only 100~200 packages, will have to add dependency exceptions for
several architectures, and we all know how these kind of changes happen
in Debian: from very slow progress to complete stalls for months.
There're always good chances to stumble upon unmaintained packages,
different sorts of entanglements ("cannot be uploaded until this of that
is resolved"), or even --fortunately in a very small handful of cases--
maintainers unwilling to make things happen.
Not to pick specifically on your reply, but to continue with this
example of dependencies... By using "build-rdeps" from devscripts:
Found a total of 145 reverse build-depend(s) for librsvg2-dev.
These include most of the desktops (gnome, mate) and more lenient WMs,
like afterstep and wmaker, but also vlc and ffmpeg and
gst-plugins-bad1.0 (gstreamer). Everyone can imagine that this removes
a big percentage of the packages in the archive.
That's not all, as there are many dependencies of librsvg2-bin:
Found a total of 5832 reverse build-depend(s) for librsvg2-2.
Using only the ones directly build-depending on it (ignoring virtual
deps), with "build-rdeps --old":
Found a total of 72 reverse build-depend(s) for librsvg2-bin.
This includes among others: gnupg2, cups-filters, debian-installer.
I don't want to bore all of you to death with examples, but there's a
big difference between direct (build-)dependencies and all the packages
that need to be working in a given architecture in order to be able to
compile a package, and keep the whole thing up to date as packages get
uploaded to unstable.
By making librsvg unavailable for an architecture, many packages will
not be able to build if rebootstrapped again, in all of those not having
Rust ready. As Adam says, the % of the archive will eventually degrade
to this number in all architectures which cannot use the newer
src:librsvg (due to removal of packages, transitions and so on). All
arches in debian-ports can do more than 75% now, and some almost 90% or
more, but this would be impossible without librsvg:
https://buildd.debian.org/stats/graph-ports-quarter-big.png
A regression of this scale shouldn't be done lightly. So what about
reverting it now so things don't degrade, then having a flamewar what to do?
We already know what to do, which is to prioritise our upcoming release
and the architectures that will be included in it. We do not allow
Debian ports to hold back changes in unstable.
I think that this is a reasonable assumption in general if the breakage
is small, but I am not sure if this is the case when in one single blow
a few architectures are completely removed from the table (and new
architectures too, until they get a LLVM and Rust port, along with all
other necessary support in other tools).
For example RISC-V / riscv64 will probably not have LLVM ready at least
until the LLVM stable released next March.
Maybe in this case there are other solutions, like keeping librsvg-rust
and librsvg-c for different architectures.
But still, it would be nice to have some reassurance for the people
working in ports that the effort spent will not be swept away from one
day to the next just because of a single package, without further
discussion or trying to find acceptable solutions.
Also, that there's a bit of an irony in this case, not specially funny
for Adrian. He just made Rust work in new architectures [1], including
the mips* stable-release-supported architectures. And it's only as a
result of this that a few days later a new src:librsvg implemented in
Rust can be uploaded to unstable, otherwise it couldn't.
So the repayment for him to spend time and make Rust work in many
architectures, is to blow away his work in a lot of other arches. Not
nice.
[1] https://lists.debian.org/debian-devel-announce/2018/11/msg00000.html
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: