[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
>
>
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.
Regards,
Gerry
More information about the Distutils-SIG
mailing list