python-cryptography vs. stainless steel ports

Hi,

we have still the situation that the current python-cryptography,
having rather heavy rust ecosystem dependencies, cannot be built
on some debian-ports architectures.

This situation is not likely to go away:

=E2=80=A2 some ports are unlikely to meet the dependencies soon
=E2=80=A2 new ports won=E2=80=99t meet them at first even if they may meet
  them later (riscv64 and loong64 now meet them)

For the t64 transition, I *think* I can just binNMU the last
version that worked and porter-upload that, but that=E2=80=99s not a
workable long-term solution, especially when python transitions
come, etc.

Is there a chance your team could fork the old python-cryptography
source package (3.4.8-2) and do something like:

=E2=80=A2 rename its python3-cryptography binary package to
  python3-cryptography-rustless or something
=E2=80=A2 let that Provide python3-cryptography in the same version

Making python3-cryptography-rustless available on all arches
has the benefit that people can test that their code will work
on ports arches without having to bother installing one of them.

I=E2=80=99m not entirely sure that having python3-cryptography-rustless
Provides python3-cryptography, then other packages B-D/Depends
python3-cryptography will work; IIRC, there was something about
the first alternative must not be virtual and buildds won=E2=80=99t use
second+ alternatives. In that case, we=E2=80=99ll instead need the
python3-cryptography-rustless source package to build a second
binary package python3-cryptography either as arch:all but in a
lower version than the python-cryptography=E2=80=99s (if that=E2=80=99s oka=
y),
or as arch:any on just the affected architectures (which will
end up being an annoying to maintain whitelist) that Depends
python3-cryptography-rustless, to keep things installable on
the buildds.

With this in unstable proper, debian-ports will have a much
easier job, and maintainers (both of the python3-cryptography
ecosystem/packages and of software using it) can more easily
test things work, and your team can apply whatever new policy
changes, dh-* helpers, etc. to the 3.4.8-based package, and
backport bugfixes, etc. (and perhaps there=E2=80=99s even an upstream
fork?).

The arches currently split as:

=E2=80=A2 alpha=09=093.4.8-2
=E2=80=A2 hppa=09=093.4.8-2
=E2=80=A2 hurd-amd64=093.4.8-2
=E2=80=A2 hurd-arm64=09unknown, probably 3.x
=E2=80=A2 hurd-i386=093.4.8-2
=E2=80=A2 ia64=09=093.4.8-2
=E2=80=A2 loong64=0941.0.7-5
=E2=80=A2 m68k=09=093.4.8-2
=E2=80=A2 powerpc=0941.0.7-3
=E2=80=A2 ppc64=09=0941.0.7-5
=E2=80=A2 sh4=09=093.4.8-2
=E2=80=A2 sparc64=0941.0.7-5
=E2=80=A2 x32=09=0938.0.4-4

(x32 seems to be lagging in the rust department, too=E2=80=A6)

Since this exists mostly to help d-ports, it would be fine to
open an RC bug against it early to prevent it from showing up
in releases, if desired.

Thanks for considering,
//mirabilos, helping out m68k for the time_t transition again
--=20
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival