Hi Sergei, On Thu, Dec 14, 2023 at 06:22:45PM +0300, Sergei Golovan wrote: > I'm sorry, I wasn't aware about these implications. Meanwhile, I'm > setting this bug > severity to serious and will fix it as soon as possible.
Thank you. I agree that this is surprising at times. Hence, I'm looking after this. :) > > I suggest that you temporarily revert this change in unstable to restore > > the ability to bootstrap Debian from source. > > I'll do that. Thank you. > Can someone investigate if blt is really necessary for Python now? This is a very difficult question I fear. A very common approach for dropping dependencies is using reproducible builds as a QA tool: If the package builds and has the same output artifact with a dependency removed, it probably isn't used during build (but maybe used for testing). Please keep in mind that any build dependency annotated <!nocheck> is irrelevant to bootstrapping problems, so this is quite powerful normally. Unfortunately, Python is not very reproducible. It embeds the build path into lots of places. It uses profile guided optimization and even if you build with DEB_BUILD_OPTIONS=nopgo, you still get lots of variations. The python$VER package used to contain tk, but since a while we have python3-stdlib-extensions. It feels fairly natural that python$VER should no longer need tk and blt. I went a head and tried reproducing this. On the good side, that build succeeded. The resulting artifacts still differed a lot from an unmodified build and in particular, the _uuid.so and _nis.so module went missing. The former probably is due to something from tk or blt issuing a dependency on uuid-dev and with those packages removed, uuid-dev was no longer pulled. I have not found a probably cause for the nis module. So from the outset it seems that breaking the cycle at Python is plausible, but it needs more validation work. Possibly, blt is still being used for testing the build and that's fine as long as it is annotated <!nocheck>. (Do note that a failure to build from source with the nocheck profile enabled is considered to be an rc bug since trixie.) > Again, I'll revert the change shortly, but is there any way I can help > with untangling Python from blt? If you are up for doing that work, I definitely appreciate that. As detailed earlier, this probably involves changing python's Build-Depends only. Adding uuid-dev and probably other packages that currently are implied and then dropping or annotating blt-dev and probably also tk-dev. That validation work is what takes time. At a bare minimum, one needs to fix a build path and use DEB_BUILD_OPTIONS=nopgo, but I suspect that even that isn't enough to get variations down to a manageable level. I'm all for removing blt from the bootstrap set in general. Though keep in mind that you won't be removing it from python3-stdlib-extensions and python3-tk has 500+ build-rdeps, so your luck with being removed from bootstrap may vary. Helmut
