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.
xxx
Description: Binary data
debian.tar.gz
Description: Binary data
