Lintian checking ARB packages

Niels Thykier niels at thykier.net
Thu Dec 27 10:35:15 UTC 2012


On 2012-12-27 06:21, Bhavani Shankar R wrote:
> [...]
> 
> Thanks Niels,
> 
> After some tweaking latest revision of the branch
> http://bazaar.launchpad.net/~bhavi/ubuntu-app-review-board/lintian-arb_profile
> works fine at runtime with namespace checks.
> 

Great. :)

> A small question I have here, Is there a way to integrate source
> package tests in lintian for example in arb-lint the sourcepackages.py
> file checks the source tar.gz file and as far as I know lintian is
> used on .changes file or dsc or the deb after generating the same from
> dpkg-buildpackage,
> 

Yes, Lintian can check .dsc files and the related (.orig).tar.$comp
files.   The built-in checks "debhelper" and "debian-source-dir" are
examples of this.  Basically, the "Type" field in the .desc should
contain "source" and the check will run on source packages.

That said, the source checks apply to the built .dsc and not the
unpacked package tree.  So there are some of the arb-lint checks that
cannot be turned into a Lintian check[1].

I had a quick look at the current arb-lint checks and I don't think it
would make sense to implement:

 * test_has_debian_{dir,rules,control,changelog}
   - Cannot be built and cannot be unpacked/checked
 * test_has_copyright
   - I believe Lintian has this as a W flag already.  You can increase
     the severity of it, if needed.
 * test_for_unused_cdbs
   - I think there is a check for this in Lintian as well.

For the rest:

 * test_uses_dep5
   - Maybe this should be in checks/source-copyright as a tag disabled
     in debian/main (and possibly also in ubuntu/main).  Though, you can
     probably use checks/source-copyright as an example here, if not.
 * test_uses_deprecated_python_installation
   - Lintian already has some related checks but only for the dh_*
     helpers.  It is possible that Lintian should have a full check for
     this in Jessie.  I am not really up to speed with Python packaging
     in Debian, so you probably have to speak with some Python people.
 * test_for_uptodate_standards_version:
   - checks/standards-version might be a good example.

 * test_for_multiple_changelog_entries
   - $info->changelog might be useful.
 * test_has_maintainer_scripts
   - checks/debhelper might be useful as an example.
 * test_is_lightweight_app
   - checks/cruft might be useful as an example (e.g. File::Find
     and $info->unpacked)

 * test_conflicts_replaces_breaks:
   - Unless you intend to allow Breaks/Replaces/Conflicts via subst
     variables (or/and generated via tools), I would probably do this
     in a binary check.  For a binary check it is:

       if (defined $info->field ('<field>')) {
           tag 'field-not-allowed-...', '<field>';
       }

    For a source check it is:

       foreach my $binpkg ($info->binaries) {
           if (defined $info->binary_field ($binpkg, '<field>')) {
               tag 'field-not-allowed-...', $binpkg, '<field>';
           }
       }

> Thanks a lot again Niels for all your inputs.
> 
> Regards,
> 
> 

[1] e.g. dpkg-source rules d/rules clean before building the source
package, so test_has_debian_rules will probably be useless in a Lintian
context unless/until #262783 is fixed.



More information about the App-review-board mailing list