[Distutils] Packaging: bdist_deb patches

[Paul Moore]

2009/6/8 Tarek Ziadé <ziade.tarek at gmail.com>:
> During the summit at Pycon, we have said that it would be a better
> strategy not to include
> within Distutils os-specific tools for various reasons (and also to
> remove existing ones) :
>
> - it's better for them to have their own release cycles

I don't see why. The one I'm interested in (bdist_wininst) doesn't
change often, and doesn't need a different release cycle (IMHO).

> - it's hard for me, as distutils maintainer, to maintain and make
> evolve os-specific tools. People that are specialists on those OS
>  will do a better job.

Sorry, but while I appreciate your difficulty, that's not a good
enough reason. The rest of Python core is maintained by people who
don't have access to all OSes. Packages like subprocess and threading
manage. Just take patches from interested community members - you act
as a manager rather than a developer in those areas, but that's OK.

> Now the problems to reach that goal are:
>
> - some people are reluctant not to have everything included in the
> stdlib (I am not). I don't think we can all agree on this,
>  and since Guido have encouraged this strategy during the summit, I
> guess I'm more inclined to follow it nevertheless.

While "Guido says so" beats any other argument, I'd like to hear some
good reasons - at least for bdist_wininst. For the Linux package
formats, where there's a lot of interest in packaging and strong views
on what's "right", I can see the point. For Windows, where nobody gets
excited about it, moving bdist_wininst out of the core risks nobody
caring enough to keep it going, and thus no packaging solution at all
on Windows.

> - we need to detect for each existing command (rpm, etc) a project
> that can take over, prior to remove it from Distutils
> when appliable .

And a policy on what to do if no such project can be found.

Paul.