[Distutils] Packaging: bdist_deb patches

Leonardo Santagada santagada at gmail.com
Tue Jun 9 22:42:15 CEST 2009

On Jun 9, 2009, at 1:45 PM, Gerry Reno wrote:
> 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.

What exactly you mean by all these? If I'm not mistaken only rpm,  
windows and a generic unixy binary packages exists in distutils today,  
and rpm packages are hardly close to a windows installer package (in  
terms of install scripts etc) so I don't see what you mean by they  
being the same now and your fear of they growing different.

Also I don't see how having a bit of code inside the stdlib is easier  
to maintain than code outside it. Seeing how long a patch takes to be  
applied in the stdlib and how no one can receive commit rights to work  
on just a submodule of it I think that working as an outside project  
is actually beneficial to all those projects in case something change  
on their package tool, and if nothing changes they can keep up pretty  
easily with distutils.

ps: Tarek is one of the exceptions right? He works only on distutils.

Leonardo Santagada
santagada at gmail.com

More information about the Distutils-SIG mailing list