On 24.03.2018 03:35, Simon McVittie wrote: > 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
and once the current dh-python package moves to testing, dh-python will gain a dependency on python3-distutils. > 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. distutils is a build tool, and we should not need it in a runtime environment. It looks like .version is used too much in a runtime context, but that should be the only subpackage used in a runtime context. sysconfig should be preferred over distutils.sysconfig in python3. > 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 >
