Le lun. 11 mars 2024 à 20:17, Thorsten Glaser <t...@debian.org> 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-amd64 3.4.8-2 > • hurd-arm64 unknown, 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
