Greg Ward writes: > On 28 June 2000, Matthias Klose said: > > Thanks. I was packaging distutils for Debian before python1.6 hits the > > Debian archives. > > For people with Python 1.5.2 installations, right? (Obviously, > Distutils will be included with Python 1.6.) Yes, Debian currently has 1.5.2 in all distributions (potato and woody). The current distutils version will then be replaced with the version included in 1.6. > BTW, what's the Debian policy (if any) for installing third-party > modules from a .deb package? The only precedent I have noted is that > Red Hat puts the PyGTK interface into site-packages, which seems > reasonable. It's a bit weird because it means a brand-spanking-new > installation has stuff in site-packages, but the alternatives seem > worse. What's Debian's answer? Currently most packages are put into a subdirectory of site-packages, so you can determinate with one look, which file belongs to which package (although there are other tools which do exactly this). > (Distutils-generated RPMs are the same as Red Hat's -- and if Distutils > grows a command to generate Debian packages, they really should act the > same as it RPMs!) Debian is more strict in makeing packages (see the Debian packaging manual and the debian policy). http://www.debian.org/doc/packaging-manuals/packaging.html/ http://www.debian.org/doc/debian-policy/ I am sure, that something more (than the package author thinks) needs to be added to many packages to match Debian's policies. For your interest I have added the debian subdirectory for distutils. As you can see, there is not much added to the standard build procedures. The question is: what exactly could be done to support the Debian package format? - make an option not to compile .py files (they are compiled when installing the package --> package gets smaller and you may compile with -O as well) - install documentation; as you can see, I didn't put much effort in this. But the generation of html and pdf/ps documents could be eased. There are other files, which have to be copied manually. - provide support for multiple binary packages. For example the pil source package is divided into four subpackages (python-imaging, python-imaging-tk, python-imaging-sane, python-imaging-doc), so that a sub package can be installed without all the dependent libraries. (For example python-imaging can be installed without having installed X). Other subpackages are used to separate the development files from the runtime files, or to put big documentation files in it's own subpackage. - add dependency information (build-Dependencies and runtime-dependencies) that could be extracted to the debian/control file.
Attachment:
xxx
Description: Binary data
Attachment:
debian.tar.gz
Description: Binary data