From: noisycoil@debian.org 
  
 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! 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)