[Pkg-rust-maintainers] Bug#1115714: Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev

[Jonas Smedegaard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20250920/6b98a113/attachment-0001.sig>