Bug#444642: lintian: python-all is a valid build-dep for arch:all packages

[Bernd Zeimetz <bernd@bzed.de>]

reopen 444642
found 444642 1.23.36
thanks

As lintian still complains about python-all within build-dep I'm
reopening the bug as it's only fixed to 50% imho.

I: nouvelle source: build-depends-without-arch-dep python-all
N:
N:   The control file lists the given package in Build-Depends, but no
N:   architecture-dependent packages are built. If all the packages built
N:   are architecture-independent, the only packages that should be listed
N:   in Build-Depends are those required to run the clean target (such as
N:   debhelper if you use dh_clean). Other build dependencies should be
N:   listed in Build-Depends-Indep instead.
N:
N:   Refer to Policy Manual, section 7.6 for details.
N:


here's a follow up to a mail from you:

> You are going to have to be more specific for lintian to be taught to tell
> that, since the package build infrastructure itself certainly doesn't
> require that python-all be installed for the clean target.  :)  What
> specific program are you running or action are you taking in the clean
> target that requires python?  lintian tries to detect such usages, so I
> need to know what it's missing.
> 


Imho the reason for tehis problem is the regexp in checks/fields, line 90.
        [ $python_depend => '^\t\s*python\s' ],
It assumes that one calls setup.py clean with python, which is not the
case if you call it for all python versions, like

        for py in $(PYVERS); do  \
                $$py setup.py clean; \
        done

A better regexp would probably something like
'^\t.+setup.py\s+clean'
I'm not 100% sure about the \s+ - I can imagine that once could want to
pass other arguments to setup.py there (like -v or -q).
So something like
'^\t.+setup.py.+clean'
should be exact enough and still give the maintainer the freedom to pass
 flags to setup.py enough.
Therefore please replace the line mentioned above by
        [ $python_depend => '^\t.+setup.py.+clean' ],

Unfortunately this doesn't count for packages which use some weird
homemade install systems, but so far I've seen them only for arch:any
packages, and even there they're rare - so I think we can safely ignore
this and stick with packages using setup.py.

Best regards,

Bernd
-- 
Bernd Zeimetz
<bernd@bzed.de>                         <http://bzed.de/>