On 9/21/25 11:05 PM, Jonas Smedegaard wrote:
Quoting NoisyCoil (2025-09-21 22:26:04)
On 21/09/25 10:41, Jonas Smedegaard wrote:
> Please do not knowingly destabilize Debian unstable, but release known
> broken packages to experimental, re-releasing to unstable only when
> dependencies are all there.
[...] there's no such thing as
*knowingly* uploading broken packages to unstable in Rust team.
[...]
what we do allow is uploading multiple dependent
packages to unstable/NEW at the same time.
Please do not do that. When you know(!) that dependencies are not
satisfied but are at the risk of month-long NEW queue processing,
upload to experimental instead of to unstable.
How do we know that? My most recent experiences with the NEW queue was
that it was fast. Now, post-release it seems to be slow again. I also
uploaded a couple of Go packages to unstable/NEW. I did not expect it to
take weeks. But those are new leaves. So is librust-tower-lsp-dev.
It feels like a lot of your questions could be answered by an "apt-get
install --dry-run" in unstable. And Britney ensures that these would
never get put into testing.
If you break an existing package that has reverse-dependencies, that's a
problem. If you don't upload the dependencies at all (rather than them
being stuck in NEW or getting rejected), that's a problem. And there
should be an assumption that you do resolve breakage. There does not
seem to be disagreement about that. Maybe we eventually need a way to
atomically install a set of packages together, i.e. group them in NEW.
I don't think the experimental bit materially changes much. The package
would still exist and you would not be able to update it without NMUing
it. You would still not be able to make use of it for your own package.
Kind regards
Philipp Kern
