Two quick thoughts from my mobile: Since transitioning through NEW takes so long, I typically upload as much of the dependency tree as possible. But NEW is not a FIFO, so sometimes thing pop out that is not buildable. A similar problem happens if something is in NEW a long time and upgrades of it's deps happen.
And regarding running tests in debug, debug have additional checks for numeric over-/underflows, something that easily happens when switching between 64 and 32 bit architectures. I believe we catch more bugs if we don't run the tests with --release. //Alex On Sat, Sep 20, 2025, 15:48 NoisyCoil <[email protected]> wrote: > 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! > >
