[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

distutils -- forwarded message from Greg Ward

--- Begin Message --- 
On 29 June 2000, Matthias Klose said:
> 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.

Strictly speaking, it would be better to replace it with "Distutils 1.0"
(maybe 1.0.1, 1.0.2 -- whatever) -- this will be an independent release
of the code included in Python 1.6.  (Actually, I just learned today:
Python 1.6 is dead, long live Python 2.0!  Dunno if this has been
publicly announced, so please keep it under your hat until you see an
announcement from Guido... probably the announcement of 2.0b1 on
Saturday.)  But that's a semantic quibble -- the code should be the
same.

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

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

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

Strictly speaking, the Distutils docs are part of the Python
documentation -- you're not going to be able to build them without
having all the Python doc tools at hand, in which case you have
alternate copies of the Distutils manuals.  Hence the poor support in
Distutils for its own docs (sorry).  (The LaTeX source is really only
there for completeness and so people can provide patches.)

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

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

        Greg
-- 
Greg Ward - Unix nerd                                   gward@python.net
http://starship.python.net/~gward/
Laziness, Impatience, Hubris.

--- End Message ---
Reply to: