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 ...
