Re: Hard Rust requirements from May onward
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Sun, Nov 02, 2025 at 01:08:06PM +0100, Joerg Jaspert wrote:
>...
> I think that shouldn't be on one maintainers decision alone.
>...
In addition to that, discussion of relevant topics that would be part of
any normal decision process is also missing.
Like people tend to forget about [1].
Has the Security team committed to change that in forky?
Has the Archive Operations Team committed to fixing their part of that?
Is all tooling automatic enough that handling 1k binNMUs per
architecture as part of a DSA or point release wouldn't cause problems?
Is anyone working on different binNMU version numbering in stable releases?
Status quo is that sing Rust would reduce security support for apt.
sqv (used by apt in trixie) is already affected by this.
It has been known and discussed for a decade that we are not setup for
security support of static-only ecosystems, and I do not have the
impression that the proponents of more Rust in Debian care about
security.
Part of the discussion in this thread is based on the one positive
aspect of that email:
> On 17764 March 1977, Julian Andres Klode wrote:
> >...
> > If you maintain a port without a working Rust toolchain,
> > please ensure it has one within the next 6 months, or
> > sunset the port.
> >...
This is a commitment by the maintainer that apt will only require
"a"/"one" working Rust toolchain, not (directly or indirectly) depend on
some specific toolchain - and people working on the ports in question
are now discussing and working based on that commitment.
I hope the toxic behaviour of the maintainer won't continue with
backtracking on that commitment.
Is there a technical reason why an apt-legacy package using the trixie
version of apt for a few more years would not be a short-term option for
ports that need more than 6 months for getting a working gccrs?
That would be simple to do and even comes with several years of security
support, and the apt maintainer should be able to explain and discuss
at what point it might run into compatibility issues.
Starting to use rust crates at some point would bring the hellscape of
semantic versioning. I have the impression that incompatible API breaks
are at least an order of magnitude more frequent in the Rust ecosystem
than in the C/C++ ecosystem, and this would be a problem for core native
Debian code with a bus factor of 1.
There are likely more topics that should be discussed before
a decision to make the first core component of Debian use Rust.
cu
Adrian
[1] https://www.debian.org/releases/trixie/release-notes/issues.html#go-and-rust-based-packages
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAmkJJc4ACgkQiNJCh6LY
mLGnMQ//eclPxi4e007IXoEladKy/o9tb+cbZNwDH2YbN1uZHxCSv7vxLYI4FLCi
5tmmjErD6to2T7uS+wJd7IFDqhEUh38Paiafsb8nOinD+H8T2IWqnWpbDz+49bf7
fyusrBu6IVif2Dl3ve2YwRtT9F21DzeAavzEmLLngR1hpmA3lTVa3PhT17Zb7i2l
BsdeiRYeDjCcxMxXaPJ81xV8wfswUrRppKY9LHYD8HSbUt3Qy6gUeTHSRaTotKga
ZzokDNIu5v/qI6llLrroI1jOqD3UyR8IVk/pgWb927N0OJ9X+rnFdYbS6sVLZ5V4
Kw7EYE2CtxZXRwk+2Bd2iniWwopwBHiDJG3+bu4IXhNVfQQezNBYH/Fna/Y6blND
pYN+OcwHs2AhHQSVi7APqkRzGh15N1q3HLL0ZzPjGPEyb4Q3fuwStrn4jY9pbmSg
TVERZLg8gDMvWgZg6J7ZWHm/JJUbabucQkX551aaJLwzcPaKlUNWxV35IMOfuayC
dEUwIPuSrG+BQ+da757JIYjNbCzEkBZj3HJdzL0m7zOCcqSbW8LLSQpcso8dvBVX
wz9aWO7lJi2Jmf5jyV1eHJFVk5wcd4p3JcS8x5FaYTM1Sba0FbU4vEY8TY1bNUkp
3wxTtOuidWg/Tk5mPzEP1Kj+pLr3QzoQSZXzoP4pMHcMTo04PWM=
=lkUe
-----END PGP SIGNATURE-----
Reply to: