Hi PICCA (2024.11.13_10:04:26_+0000) > I am a bit worrying for the scientific stack , will we have enough > time to work with our upstream in order to fix all these FTBFS. In the > scientific stack, things are going slowly....
The reality here is that Python has a 6-month release cycle, these days. If upstreams can't stay on top of new Python releases, we are stuck with doing the porting work or dropping them from Debian. We can't fix them all in 6 months. There are still a lot of open 3.11 and 3.12 bugs, for example. If we don't have the latest stable version of Python in our stable release, I think a large number of our users will be very disappointed. It would certainly cement the view that Debian ships ancient software. I don't think the users who would be upset would have any motivation to help improve the situation (working on old scientific packages). If we have to drop large numbers of scientific packages in our stable releases, I imagine a small number of users would be disappointed, and hopefully able to see how they can help avoid this situation in the future. Sorry, but I see that as the less bad outcome. I'm not saying I want it, but I think it's the approach we have to take, in the face of unmaintained software. The alternative would be to carry multiple Python releases in a Debian stable release, which is something we haven't wanted to do. We try to start the detection process as early as possible. I have been doing archive wide rebuilds (as much as I could, on arm64) since 3.13 rc2. I announced it, and our planned migration to 3.13 in trixie, in: https://lists.debian.org/msgid-search/20240920072725.mkhi575oydnr6...@satie.tumbleweed.org.za I'm hoping to have even better tooling for this kind of rebuild in the future. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
