On 2009-03-27 15:00, Ronald Oussoren wrote: > > 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.
Hmm, I have heard different things - see my reply to Olemis :-) Besides, the bdist_rpm command as well as the others are not only for Linux distributors to use, but to help developers ship their packages to their users *without* the help of some distribution, ie. by providing an RPM or DEB file for download. > 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. Fair enough, though, I'm sure we have enough developer knowledge on board to maintain bdist_rpm and add a bdist_deb. Perhaps even an bdist_dmg :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 27 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ 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