[Pkg-rust-maintainers] Bug#969609: Bug#969609: Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe

[Ximin Luo]

Steve Langasek:
> Ximin,
> 
> On Tue, Sep 08, 2020 at 09:23:49PM +0100, Ximin Luo wrote:
>> You keep filing these same bugs.  I have told you this many times before
>> already: this is just how rust packaging works, Britney's migration policy
>> already prevents these packages from reaching Debian Testing, so there is
>> no problem, no users are affected.
> 
>> You filing these bug reports accomplishes nothing, except delay & annoy
>> other Rust packagers who forget to close these pointless bugs, thereby
>> unnecessarily blocking any fixed packages from actually reaching Debian
>> Testing.  Oftentimes the fix is also not to update the package itself, but
>> to upload another package.  Due to the idiosyncracies of the BTS, not
>> everyone knows how to close these bugs correctly (notfound -1 $version)
>> and it will result in further delays.
> 
>> Please stop filing these bug reports, they only create extra unnecessary
>> work for other people, and make Debian worse for users, by slowing down
>> the stream of fixes.  Britney already prevents Testing migration.
> 
> It is not credible to me that this is "just how rust packaging works".  The
> bugs I am filing are against packages that have been uninstallable in
> unstable for more than 4 months.  The missing dependencies are not in the
> NEW queue, and there are no ITP bugs filed for them.  There is no reason to
> believe, without filing these bugs, that anyone on the rust packaging team
> is doing anything about these missing dependencies.
> 

Why is it not credible? I am one of the main members of the team, and created about 80% of the current process. I am telling you it is simply how it works. If you want an in-depth description, see https://github.com/kpcyrd/cargo-debstatus/issues/2. In summary, it is because the Rust dependency system encodes complex dependency relationships in a more efficient way than the Debian dependency system, meaning the typical Rust package expresses more complex dependencies than most other Debian packages. But you can get this type of situation with other languages too, especially those with bootstrap loops. The only difference is in Rust it's much more common.

(The NEW queue is another unresolved issue that is blocking Rust packaging - we have a policy disagreement with the FTP team and nobody has had time to resolve it. That is why things might not be on the NEW queue.)

At the end of the day, it doesn't matter if people don't do anything about these missing dependencies, because *the britney migration script prevents migration to testing*. For the packages that matter, i.e. that need to be migrated to testing (& eventually stable), members of this team are forced to fix these issues anyway, and we have a documented process for doing this:

https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/RELEASE.rst

> And filing bug reports in the Debian BTS is the standard way in Debian to
> document bugs in packages.
> 
> And it is unacceptable that Debian maintainers don't know how to operate the
> Debian BTS.
> 

Most Debian Rust Team members are not regular Debian maintainers. And the Debian BTS user interface is really unintuitive. So I can't reasonably consider it "unacceptable", we have to be realistic regarding volunteer on-boarding.

> So no, I will not stop filing bugs against RC-buggy packages that the Rust
> maintainers are clearly not taking care of.  If you don't want bug reports,
> you have the option to stop uploading packages that are RC buggy from the
> moment they're accepted into the archive.
> 

I am explaining to you why the normal Debian process is inadequate and causes more work for everyone in this case. Please trust your fellow maintainers more on matters on which they have more expertise. After all of my explanations, what benefit do you suppose these bugs are giving?? You filing bug reports is not going to magically give people more free time to fix them; when they have the free time these problems are automatically and forcibly solved as part of our regular process. The bugs do not help this one bit.

Best
Ximin

-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git