Quoting NoisyCoil (2025-09-20 01:23:53) > On 19/09/25 23:56, Jonas Smedegaard wrote: > > Why are such inconsistencies done in unstable? Have the Rust team > > considered using experimental for preparing such reorganisations, and > > if not, why not? > > This has nothing to do with "reorganizations". The actual issue here is > that zerovec, for whatever reason, was uploaded to unstable with missing > dependencies from the very start (AFAICS). > > As for "reorganizations" (transitions? semver-breaking updates?) in > general, we always prepare them in experimental if they involve packages > not maintained by the Rust Team. You must know this, given that we > regularly file a large number of bug reports to your packages for this > exact purpose. > > As for *this* specific "reorganization" (transition), it is only being > discussed because I determined that the best way to fix zerovec, that as > I said has been broken in unstable for as long as it has been there > (again AFAICS), is indeed updating twox-hash to v2: the xxhash64 feature > is missing from v1, and zerovec's hashmap feature needs it; moreover, > some of the changes needed to update to twox-hash v2 were already staged > in git months ago, so updating would allow us to upload those pending > changes. Note that the transition hasn't started yet: the other packages > involved are perfectly fine with v1, the update would only concretely > benefit zerovec and we would probably not even be talking about it right > now were it not for this bug report. Since however zerovec also requires > packaging yoke-derive to be fully fixed, starting this transition now is > simply not worth it. When we will start the transition (after > yoke-derive is packaged [1]), since sourmash is mainly maintained by the > Debian Med Team, it will likely go through experimental -- unless they > greenlight an NMU. > > As an alternative, since, again, this is ultimately only about zerovec, > if you need it quickly and don't need its hashmap (requiring twox-hash > v2) or yoke (requiring yoke, thus yoke-derive) features, we could try to > speed this up a bit by patching those dependencies out temporarily (I > haven't tried this out). > > Sorry for not making the situation clearer before, I'd already spent the > whole day writing stuff for $WORK, was trying to get away with less > writing :-) It seems you are reflecting on ways to move forward with the concrete issue. 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? In your reflections above, you seem to consider experimental a place for cross *team* coordination. 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. - Jonas ¹ https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=unstable;include=subject%3Aimpossible;submitter=dr%40jones.dk -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature