Bug#893924: python3-distutils: Please describe road map/recommendations for users of distutils
Package: python3-distutils
Version: 3.6.5~rc1-2
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
I'm confused about the current status of distutils, and what should be
done by packages that depend on it to be as future-proof as possible. I
don't think I'm the only one confused by this, so it would be very
helpful if a maintainer could clarify what the intention is so that
other maintainers can do the right things.
When structural changes like this are needed, I think it would
be useful for them to be represented by a bug (perhaps of the form
"libpython3.6-stdlib: should not contain distutils" or something similar)
that gives the reasons for the structural change and describes the
action that should be taken by maintainers of dependent packages. This
bug could be referenced in the changelog and would be an obvious central
coordination point for whatever changes are needed, including follow-ups
if unforeseen fallout means the plan has to change. The release team
would probably also appreciate it being treated as a transition so that
they can plan around it.
Since that didn't happen in this case, I'm opening this bug in the hope
that it can fulfil a similar role.
So far, the sequence of events goes something like this:
* 13 December 2017: distutils moves from -stdlib into its own package
* 20 March 2018: -stdlib stops depending on distutils, packages start
to fail to build from source
* 22-23 March 2018: A small subset of distutils (__init__.py and version.py)
moves back to -stdlib
I assume there is a reason (size on disk? dependencies? update
frequency?) why most of distutils shouldn't be in -stdlib, but in the
absence of a reference in the changelog, I can only guess at why that is.
When a small subset of distutils moved back, I assume that the
intention was to un-break the relatively common(?) case of users of
distutils.version that do not need the rest of the module, such as
the gdbus-codegen tool in libglib2.0-dev-bin. However, it isn't clear
whether the Python maintainers consider this to be a workaround to keep
those packages working in the short term (in which case they need to
pick up a new dependency on python3-distutils for the longer term), or
whether distutils.version is going to remain part of the API of -stdlib
in the long term (in which case packages like libglib2.0-dev-bin should
not depend on the full -distutils package because that would negate the
benefit of splitting it out).
I'm aware that structural changes that break dependencies are sometimes
necessary in pursuit of a goal (I've done them myself, most recently
moving glib-compile-resources to libglib2.0-dev-bin for #885019), but
when making them, having a plan visible to everyone is beneficial.
Please could you clarify the situation?
Related bug reports include:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893755
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893847
Thanks,
smcv
Reply to: