Dropping cc on bug report and replacing pkg-rust-maintainers with
debian-rust, as these are policy discussions.
On 20/09/25 10:31, Jonas Smedegaard wrote:
My question is aimed at something else: Why did this happen in the first
place? I ask with this case as a concrete example, but I have filed
numerous bugreports¹ for Rust packages having broken dependencies, and
my aim here is to address what I suspect is a more general issue:
Why do the Rust team upload known broken packages to unstable?
There is no policy in Rust Team allowing broken packages in unstable. If
a package is uninstallable in unstable, that's 100% a bug. If it's done
on purpose, that's a choice of the uploader in their personal capacity,
not reflective of team policy. Since the Rust Team maintains a large
fraction of Rust packages, broken packages usually create issues to us
too, so we aren't happy about those either.
There is, however an underlying "policy" reason why packages maintained
by the Rust Team may have an increased chance of being uninstallable.
This can happen due to a chain of events (or lack thereof) which in my
opinion is unnecessarily broken at the bottom:
1. We don't usually use piuparts. This is fine because most of the
binary packages' dependencies are source package build-dependencies:
usually, if a binary package is uninstallable, the source package is B-D
uninstallable, and we catch that as a FTBFS bug instead. Uploading a B-D
uninstallable/FTBFS package to unstable is a policy violation.
2. Crates marked as optional in Cargo.toml -- e.g. crates needed for
non-default features -- are binary dependencies but not source
build-dependencies: these missing wouldn't be caught at build-time.
Nonetheless, by default, they are autopkgtest dependencies (trivially,
because they are binary dependencies). If autopkgtests pass, it means
the package was installable. So our default minimal policy is: the
package must build and its autopkgtests must pass. As long as it does,
we don't even need to care about piuparts. Also, if they fail, it's a
(release) policy violation.
3. There is, however, a loophole here: by policy, autopkgtest are marked
as skip-not-installable by default. So if tests don't fail, but they
don't pass either, we would e.g. reject to sponsor their upload for new
contributors (again, the default policy is autopkgtest must pass), but
someone with more experience may just think "eh, I'll fix it later".
Assuming they ran autopkgtest, which they are supposed to. This is where
the chain breaks and to test installability you should use piuparts, or
whatever alternative you are.
Uninstallability is a bug regardless of its causes, but I think what I
described above may increase the chances of it happening in
Rust-Team-maintained packages. If memory serves me well (but it may very
well not :-)), at DebConf you expressed you're not happy about the
skip-not-installable policy. I agree, and I can't think of a concrete
reason why we should keep it. Note this does not mean there *isn't* a
concrete reason to do so. Other people have spent much more time than me
thinking about these issues, so a reason may very well exist.
In the same bucket, as far as I'm concerned, there's running cargo tests
in debug -- rather than release -- mode. I agree with you this is wrong:
no code is ever going to reach the Debian archive compiled in debug
mode. Again, someone with more experience than me may have a different
understanding about this.
In your reflections above, you seem to consider experimental a place
for cross*team* coordination.
No, I was only thinking about that in the context of transitions.
I urge to use experimental more generally as a staging place for cross
*package* coordination: Release known broken packages to experimental,
and then re-release to unstable only when the package is believed stable
with respect to its declared dependencies.
I'd rather we don't upload broken packages at all, but yeah, if you
must, anything but experimental surely violates policy and makes
everyone's work harder.
Cheers!
