On 10/16/20 8:04 PM, Moritz Mühlenhoff wrote: > There will be few core packages build-depending on Python 2 (for tests > or building) which won't be ready for Python 3 for Bullseye (Chromium, > qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very > small set of support packages like setuptools/jinja) to build and > run their tests. > > Apart from those there's only a handful of packages still in testing > which have a run time dependency on Python 2 packages (and most are > actively being worked on (e.g. Xen)). > > All packages (and their test suites) shipped in Debian are trusted > anyway (and consequently don't need any kind of updates during the > bullseye cycle), so a lack of updates/upstream EOL doesn't matter. > > As such, I'd propose to include Python 2 (plus the small set of > support packages) in Bullseye
ok. I think you should explicitly name all these packages. > but exempt it from support (and then > remove it for good after the Bullseye release): not ok. That would mean removing pypy3 from the archive as well. If you don't want to support Python2, then why do you care about it's removal for bullseye+1? > - Mark src:python (plus related support packages) as unsupported in > debian-security-support and with a README.Debian in the source > package (and given how prominent Python is, also in the release notes) That should list the binary packages, there's no src:python package. > - Bump the severity of the few remaining packages in testing to RC > state (and force them out testing if auto removals were blocked > for some reason) See above, I think it's unfriendly to push out pypy3. Matthias
