Le lun. 11 mars 2024 à 20:17, Thorsten Glaser a écrit :
> 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:
>
> • some ports are unlikely to meet the dependencies soon
> • new ports won’t 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’s 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:
>
> • rename its python3-cryptography binary package to
> python3-cryptography-rustless or something
> • 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’m 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’t use
> second+ alternatives. In that case, we’ll 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’s (if that’s okay),
> 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’s even an upstream
> fork?).
>
> The arches currently split as:
>
> • alpha 3.4.8-2
> • hppa 3.4.8-2
> • hurd-amd643.4.8-2
> • hurd-arm64unknown, probably 3.x
> • hurd-i386 3.4.8-2
> • ia64 3.4.8-2
> • loong64 41.0.7-5
> • m68k 3.4.8-2
> • powerpc 41.0.7-3
> • ppc64 41.0.7-5
> • sh4 3.4.8-2
> • sparc64 41.0.7-5
> • x32 38.0.4-4
>
> (x32 seems to be lagging in the rust department, too…)
>
> 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
> --
> 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
>
While I'm very much concerned about architectures and compatibility,
it seems that for python-cryptography, it's a sinking boat:
The end of a very discussion dates from february, 2021 - 3 years ago:
https://github.com/pyca/cryptography/issues/5771#issuecomment-775990406
