distutils & Debian packages
Greg Ward writes:
> On 29 June 2000, Matthias Klose said:
>
> > 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/
>
> Oh good, I'll have to take a look. I've always been impressed by the
> quality of Red Hat-generated RPMs, but they only provide an example:
> very little in the way of guideline/policy documentation. So random
> RPMs floating around the net range anywhere from very high quality
> to... ummm... not. ;-)
>
> > 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.
>
> Thanks -- I'll probably add this to the Distutils distribution, if it's
> OK by you. (I think it'll go in dist/debian -- dist is the directory
> for distribution bureacracy, such as the debian tree, the .spec file, a
> Wise script [for generating a Windows installer {someday}], etc.)
Debian needs this directory in the toplevel directory, so that a
package can be built with the "standard" commands (dpkg-buildpackage);
But the bdist_deb command could make a symlink as well.
When adding the debian directory to the upstream dist, then please
change the debian/changelog file: add a new entry with a version
<upstream>-0.1 This makes sure, that a package built by someone else
carries a version number, which is higher than the last upstream
version, and lower than the first version number given by the Debian
maintainer of the package (-1, -2, ...).
The maintainer name and changelog entry could be changed as well.
> > 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)
>
> Hmm, I thought that was there already... oh, wait, there are "--compile"
> and "--optimize" options, but no "--no-compile" or "--no-optimize".
> Oops! On the todo list, but not going to make it into Distutils 0.9.
Fine :)
> > - 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.
>
> Hmmm, *that's* a whole new can o' worms. Can't see that making it in
> for 1.0.
Agreed. Some packages already support some kind of subpackaging. pil
builds an _imaging and an _tkimaging module.
> > - add dependency information (build-Dependencies and
> > runtime-dependencies) that could be extracted to the debian/control
> > file.
>
> Not a new can o' worms, but something we have explicitly punted on.
> Post-1.0, I think.
I thought, some fields are already supported, like the author, short
descriptioon and long description. More fields could be:
- architecture dependent/independent package? I.e. with/without C
extensions, platform specific extensions.
- copyright. Even distutils is missing this (although you told me that
the python copyright applies.
- other information I missed ...
Reply to: