Package: python3-distutils Version: 3.6.5~rc1-2 Severity: wishlist X-Debbugs-Cc: debian-pyt...@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
