On 27 Mar, 2009, at 7:49, M.-A. Lemburg wrote:

On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete

Should this be read as:

- remove bdist_rpm from the stdlib and let it live on PyPI

?

Perhaps I just misunderstand the comment.

I think that esp. the bdist_* commands help developers a lot by
removing the need to know how to build e.g. RPMs or Windows
installers and let distutils deal with it.

The bdist_* commands don't really provide any higher level
functionality. They only provide interfaces to certain packaging
formats commonly used on the various platforms.

Instead of removing such functionality, I think we should add
more support for standard packaging formats to distutils, e.g.
bdist_deb, bdist_pkg, etc.

IIRC the reason for wanting to deprecate bdist_rpm (and not adding bdist_deb, ...) is that the variour Linux distributions have varying policies for how to package Python code and those policies tend to vary on another schedule than the Python development schedule. The result of this is that the Linux distributors are incapable to use bdist_rpm. It would therefore be better to ensure that Python packages / distutils can provide the metadata that's needed to build packages and move the actual creation of OS installers outside of the core where the tool can be maintained by people that have detailed knowlegde about the needs of the packaging system and system policies.

Ronald


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to