Maurice Ling <mauriceling at acm.org> wrote:
> Thank you for your pointers, Richard.

Another point that I'd like to make is that I believe we should avoid reimplementing
RPM, DEB, fink, whatever. Or at least we should not ignore them. We can produce
meta-data that supports those packaging formats. Thus a user has the opportunity to
install Python software using the existing package management mechanisms installed
in their system, rather than something new and independent just for Python. The
latest PEP I've proposed adds some meta-data that makes the DEB-alike packagers more
happy, and should also help out RPM packagers.

Distutils already does a fairly good job of handling the actual installation of
Python software -- it compiles things, can install data files, with a little extra
effort other stuff can be done too. It generates RPMs, DEBs, Windows Installers.
There's a desire from the Ubuntu packagers to add a doc_files option to the setup()
args, but that's for another discussion.

Anyway, I'm rambling. My point is clear though: I believe we should avoid developing
Yet Another Packaging System just for the sake of it. And certainly we should play
well with others where possible.

I guess we need to ask what it is that our database of installed Python modules will
achieve that the existing packaging systems don't.


    Richard
