[Python-apps-team] Bug#750871: Bug 750871 - patch

Max Bowsher _ at maxb.eu
Wed Jun 18 05:51:52 UTC 2014


On 17/06/14 23:40, Javi Merino wrote:
> Control: tags -1 - pending + wontfix
> 
> On Sat, Jun 07, 2014 at 09:35:43PM +0100, Max Bowsher wrote:
>> The problem here is that some manual sed hackery munging the /usr/bin/hg
>> shebang was removed in PAPT SVN r10748, with the justification that
>> dh_python2 would take care of it automatically.
>>
>> Unfortunately, it was not considered that the package currently circumvents
>> large portions of dh_python2's multiple python version support by calling
>> the upstream Makefile instead of setup.py.
> 
> My guess is that the dh_python2 in sid doesn't have the problem
> described in the bug, that's why I didn't see it.

That's not it - the bug is masked in sid by there only being one version
of Python 2.

>> Fortunately the solution is relatively simple:
>>
>> * Drop package-local Makefile constructs handling multiple python versions
> 
> True, that needs to be simplified.  It's been in my todo list for a
> while now.
> 
>> * Explicitly call the python_distutils debhelper buildsystem plugin
> 
> No, this is not a good idea.
> 
>> * Use override hooks to call only the upstream Makefile targets which handle
>> non-distutils parts of the build.
> 
> I don't want to replicate upstream's Makefile in debian/rules.  Today
> this may mean calling "make doc" and "make tests" by hand but you
> never know what can change in upstream's Makefile that will be lost
> because we're not using it any more.  Mercurial is meant to be built
> using the Makefile so calling distutils directly should be reduced to
> the minimum.

I suppose you can get away with this for now since upstream Python have
declared there will never be a Python 2.8.

However, by doing so you block debhelper's automatic support for
supplying the right options to setup.py, and end up having to re-add
things like --install-layout=deb within debian/rules explicitly.

I'd suggest that's as much or more of an awkward tie into the internals
of the buildsystem than my proposed patch.

Max.



More information about the Python-apps-team mailing list