In Debian bug 637398, I submitted a patch to convert the mailman package to
dh_python2. It was pointed out in a follow up, that the Python dependencies
were missing, iow, ${python:Depends} wasn't getting filled in. Indeed, close
examination of the build log, indicates that dpkg-genchanges complained about
the missing substitution variable.
The original rules file contained this:
dh_pysupport -a `find debian/mailman/usr/lib/mailman/Mailman/ -type d`
and I did a naive s/pysupport/python2/ and checked the resulting .deb, which
looked fine. I did not try to install it though (I was under a bit of a
deadline atm).
There was not much other clue as to what was going wrong in the build log,
even with DH_VERBOSE=1. Poking around after the build did confirm that
debian/mailman.substvars did not have a `python:Depends` line in it, but I
couldn't tell why.
So I ended up pdb'ing dh_python2 to figure out the problem. I first noticed
that Dependencies.export_to() from debpython/depends.py is where the substvars
are added, but this wasn't adding anything because self.depends was still
empty. I would have expected the Python dependencies in here, having been
filled out by Dependencies.parse(). But .parse() wasn't adding them because
there were no private_dirs. This led me back to dh_python2, and the scan()
function. Once I ended up here, it was pretty clear that proot was getting
calculated incorrectly, and then it dawned on me that `find...` argument to
dh_python2 in the rules file was causing a double `debian/mailman` prefix to
be added. The `find` isn't needed anyway, because dh_python2 searches
recursively.
So then I changed it to
dh_python2 -a usr/lib/mailman/Mailman
but that also (silently) failed because dh_python2 unconditionally strips the
leading character from the private_dir path, thus it tried to search
`sr/lib/mailman/Mailman`. Changing this to
dh_python2 -a /usr/lib/mailman/Mailman
fixes the problem, and solves the bug (also LP: #826795).
I'm not sure whether there's a dh_python2 bug lurking here, or what the fix
might be, but at the very least, this message might get Googled some time in
the future and hopefully help the next person with a similar bug.
I do feel like dh_python2 should help in some way here. One possibility is to
complain and exit if ${python:Depends} doesn't get filled in. When would it
ever make sense for a package that uses dh_python2 to *not* fill that in?
The unconditional removal of the first character of the private path also
bothers me. Perhaps dh_python2 should first check to see if it's a leading
slash before trying to remove it?
Maybe dh_python2 can also check the proot and not add debian/<package> if it's
already in the path?
Cheers,
-Barry
signature.asc
Description: PGP signature
