[Distutils] Re: bdist_deb patches

Geoffrey T. Dairiki dairiki at dairiki.org
Wed Oct 27 19:50:42 CEST 2004

Thanks for the comments, Sean.

On Tue, 2004-10-26 at 20:48, Sean Reifschneider wrote:
>    There's been some concern expressed about get_default_maintainer.
>    Namely, that if debchange changes it's algorithm, it won't be
>    reflected in this code.  It seems like one possible way around that
>    would be to build a directory with a "debian" directory under it, a
>    fake "changelog", and then call debchange to write the data out, and
>    parse it.

That seems like a lot of work.  Is it really worth it?

A (similar) alternative would be to use debchange
to generate the real debian/changelog.   Since debchange
fails to work unless there's already a non-empty changelog,
that entails creating an initial changelog with a dummy entry,
running debchange, and then cleaning up the dummy entry --- also
kind of messy.

>    Can _formatdate, if email doesn't exist, use rfc822.formatdate()?

rfc822.formatdate is broken in my (Debian's) python2.1 and
python2.2 in that it uses strftime (and thus day and month
names might come out in a language other than English).  Also
they do not include a numeric timezone designation.  (They
use 'GMT' rather than '-0000').  Debian policy specifies that
the zone designation "should be" numeric.  I'm not sure whether
it causes problems if it's not, but I suspect it might.

(I've just noticed that dpkg-dev includes an '822-date' program,
which could be used in lieu of formatdate, I guess.)

>    Ditto for _parseaddr?

Yes, rfc822.parseaddr will work.   Though now you've prompted
me to  take a look at how debchange parses email addresses,
and it's considerably dumber than either rfc822.parseaddr or
email.Utils.parseaddr. To wit: 

  ... $env{'DEBEMAIL'} =~ /^(.*)\s+<(.*)>$/ ...

Using debchange to generate the changelog entry would eliminate
the need for parseaddr and formatdate altogether, so perhaps that
is the best way to go.  Comments?

> ... when trying to build a .deb of my
> jotweb2 package, it's failing with:
>    [...]
>    dh_installdocs
>    cp: cannot stat `doc': No such file or directory
>    dh_installdocs: command returned error code 256
>    [...]
> I'm not sure exactly why.  I do have a "doc" directory in my main
> package directory, but I don't reference to it in my setup.py or
> MANIFEST.  Adding it to the MANIFEST doesn't seem to help this.

It looks like you don't use sdist to build your source distribution,
since it includes files which aren't in the MANIFEST.

(What's happening is that bdist_deb sees the 'doc' directory
and adds it to the default value for it's --doc-files option,
but the sdist command doesn't include the doc subdirectory in
the source distribution.  You would have to add at least one
file from the doc subdirectory to MANIFEST to fix this, I think.
A better solution might be to add 'graft doc' to MANIFEST.in.
You could also, of course, explicitly set the --doc-files option,
e.g. 'python setup.py bdist_deb --doc-files=README'.)

Overnight, I've come to believe that bdist_deb is being overly
aggressive about guessing default values for --doc-files.
I guess, at the least, that I need to make sure the assumed doc
files are in fact present in the source distribution.
(At one point, I did try using sdist --manifest-only to generate
a MANIFEST, then picking doc-files out of the MANIFEST, however
this bug was causing problems with that:)

As far as I can tell, README and README.txt are the only doc-type files
that distutils treats specially.  (They automatically get added to the
MANIFEST.)  Are there any PEPs or other standards which suggest
other standard names for doc files?

Currently, to compute the default value for --doc-files, bdist_deb
looks for the following files or directories:
  changelog, ChangeLog, and doc

After sleeping on it, my current thinking is to drop 'doc' from the
list, and only look for files (not directories).  After seeing
jotweb2, I'm think of adding 'LICENSE' and 'LICENCE' to the list.

(This turned out to be rather a longer reply than I intended.
Thanks for sticking it out to the end.)


More information about the Distutils-SIG mailing list