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
_______________________________________________
Catalog-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
