Re: Proposal on how to proceed with Python 2 removal from bullseye
> 1) all Python 2 removal bugs *can* be raised to RC level by the
> maintainers of the packages they belong to, but:
>
> 2) maintainers of non-key packages should carefully consider the
> backslash for their transitive reverse (normal, build and test)
> dependencies before raising the bug severity level and in my opinion
> should hold off doing that if there are many that need adaption for the
> Python 2 support removal. To be absolutely clear of my intent, if there
> is only a *very* limited set that needs adaption but they have a large
> set of reverse dependencies that is not what I mean here. The
> maintainers of the large set of reverse dependencies have a joint
> incentive to fix the issue if the maintainer of the to-be-adapted
> package(s) doesn't step up to fix the situation.
>
> 3) packages with unfixed reverse (normal, build or test) dependencies,
> that want to drop Python 2 support should first make sure their unfixed
> reverse dependencies have RC bugs themselves (but please take the
> consideration of 2 into account), stating at least something like
> "source package $foo is soon going to remove the binary $bar package on
> which the $baz package (build) depends, please fix that".
>
> To avoid problems with bug fixes that need to migrate to testing soon,
> please don't upload the Python 2 support drop immediately, but wait
> until either the reverse dependencies are fixed or the date for the
> autoremoval is near.
>
> 4) leaf packages (i.e. without normal, build or test reverse
> dependencies) that need to be adapted themselves for the Python 2
> removal can be marked as RC.
>
> 5) Please continue to use the approach used so far as well, but please
> also add checks on build dependencies.
i've modified the py2removal script as follow:
- extended the "real rdeps" concept as follow: while processing pkgA,
pkgB is a "real" reverse dependency of pkgA iff
-- pkgB is from another source package than pkgA (so python-foo-dbg
will not longer be marked as a rdep of python-foo, as ideally they
will get removed at the same time, as part of the same src:foo pkg)
-- if the pkgB is in testing (there are several packages in unstable
broken beyond repair, so even if we remove pkgA, it will still remain
broken but we can make progress on the py2removal front)
- added the check "real rdeps" == 0 both for modules and applications
(previously it was only for modules).
a test run shows only 3 additional severity bumps will happen when
re-enable, which i plan on doing with the next run (in 8~10 hours).
let me know if this makes sense or additional changes are required.
Regards,
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
Reply to: