[Distutils] Packaging: bdist_deb patches

Gerry Reno greno at verizon.net
Tue Jun 9 18:45:50 CEST 2009

Tarek Ziadé wrote:
> Hi Gerry,
> 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
> - 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.
> 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.
> - we need to detect for each existing command (rpm, etc) a project
> that can take over, prior to remove it from Distutils
> when appliable .
> Now, for debian, since it's not included in distutils, the question is
> : what is the most used/advanced project ? sdteb ?
> ++
> Tarek
  I understand your position on this.  However, here is what needs 
considered if you want to split out this functionality.  'bdist_rpm' 
operates rather well and you can automate the generation of packages 
using this target.  What I would hope not to see is that we end up with 
an entire fragmentation of different approaches to developing similar 
targets for other platforms such as targets like 'bdist_deb', 
'bdist_mac', etc.  Whatever group would be selected to take over this 
functionality should take over responsibility for all these targets and 
they be developed in a coordinated manner so that it would be easily 
understood by the user how to generated packages for multiple platforms 
using the targets and similar settings in setup.cfg and any auxiliary 
files similar to rpm_install_sh.txt.  If a group can be selected to 
handle these all these targets with the above goals in mind then I think 
it would be possible to split this functionality out of the core.  But, 
if the cannot be done, then I think this functionality should remain 
with the core in order to avoid fragmentation to the approaches in 
developing these 'bdist_xxx' targets.


More information about the Distutils-SIG mailing list