Removing frog.

[maemian] / checks / fields.desc

Check-Script: fields
Author: Marc 'HE' Brockschmidt <marc@marcbrockschmidt.de>
Abbrev: fld
Type: binary, udeb, source
Unpack-Level: 1
Needs-Info: debfiles, source-control-file
Info: This script checks the syntax of the fields in package control files,
 as described in the Policy Manual.

Tag: unsupported-source-format
Severity: serious
Certainty: certain
Info: This package uses a different source package format than 1.0.  At
 present, only <tt>Format: 1.0</tt> packages are permitted by the Debian
 archive software.  Newer package formats are supported by dpkg, but they
 should not yet be used for upload to Debian.

Tag: no-package-name
Severity: serious
Certainty: certain
Info: The package does not have a "Package:" field in its control file.
Ref: policy 5.3

Tag: bad-package-name
Severity: serious
Certainty: certain
Info: A package name should be at least two characters long, must consist
 of the alphanumerics and "+" "-" and ".", and must start with an
 alphanumeric character.
Ref: policy 5.6.7

Tag: package-not-lowercase
Severity: serious
Certainty: certain
Info: New packages should not use uppercase characters in their names.
Ref: policy 5.6.7

Tag: no-version-field
Severity: serious
Certainty: certain
Info: The package does not have a "Version:" field in its control file.
Ref: policy 5.3

Tag: bad-version-number
Severity: serious
Certainty: certain
Info: The version number fails one of the syntactic requirements of dpkg.
Ref: policy 5.6.12

Tag: upstream-version-not-numeric
Severity: important
Certainty: certain
Info: The upstream version number should start with a digit. 
Ref: policy 5.6.12

Tag: debian-revision-not-well-formed
Severity: normal
Certainty: certain
Info: The debian version part (the part after the -) should consist of one
 or two dot-separated parts: one for a regular maintainer release or two
 for a source-NMU.
Ref: devref 5.11.2, policy 5.6.12

Tag: debian-revision-should-not-be-zero
Severity: important
Certainty: certain
Info: The debian version part (the part after the -) should start with one,
 not with zero. This is to ensure that a correctly-done Maintainer Upload will
 always have a higher version number than a Non-Maintainer upload: a NMU could
 have been prepared which introduces this upstream version with
 Debian-revision -0.1
Ref: devref 5.11.2

Tag: no-architecture-field
Severity: serious
Certainty: certain
Info: The package does not have an "Architecture:" field in its control file.
Ref: policy 5.3

Tag: magic-arch-in-arch-list
Severity: serious
Certainty: certain
Info: The special architecture value "any" only make sense if it occurs
 alone.  The value "all" may appear together with other architectures
 in a *.dsc file but must occur alone if used in a binary package.
Ref: policy 5.6.8

Tag: unknown-architecture
Severity: normal
Certainty: possible
Info: This package claims to be for an unknown architecture.  The
 architecture should be one of the values supported by dpkg or one of the
 special values "all" or "any".  The special value "source" is only used
 in *.changes files and does not make sense in a binary package or a *.dsc
 file.

Tag: too-many-architectures
Severity: serious
Certainty: certain
Info: A binary package should list exactly one architecture (the one it is
 compiled for), or the special value "all" if it is architecture-independent.
Ref: policy 5.6.8

Tag: arch-any-in-binary-pkg
Severity: serious
Certainty: certain
Info: The special architecture value "any" does not make sense in a binary
 package.
Ref: policy 5.6.8

Tag: aspell-package-not-arch-all
Severity: normal
Certainty: certain
Info: This package appears to be an aspell dictionary package, but it is
 not Architecture: all.  The binary hashes should be built at install-time
 by calling aspell-autobuildhash, so the contents of the package should be
 architecture-independent.
Ref: aspell-autobuildhash(8)

Tag: no-maintainer-field
Severity: serious
Certainty: certain
Info: The package does not have a "Maintainer:" field in its control file.
Ref: policy 5.3

Tag: maintainer-name-missing
Severity: serious
Certainty: certain
Info: The maintainer field seems to contain just an email address. It must
 contain the package maintainer's name and email address.
Ref: policy 5.6.2

Tag: maintainer-address-missing
Severity: serious
Certainty: certain
Info: The maintainer field should contain the package maintainer's name and
 email address, with the name followed by the address inside angle
 brackets (&lt; and &gt;).  The address seems to be missing.
Ref: policy 5.6.2

Tag: maintainer-address-malformed
Severity: important
Certainty: certain
Info: The maintainer field could not be parsed according to the rules in
 the Policy Manual.
Ref: policy 5.6.2

Tag: maintainer-not-full-name
Severity: normal
Certainty: possible
Info: The "name" part of this maintainer field is just one word, so it
 might not be a full name.

Tag: maintainer-address-looks-weird
Severity: normal
Certainty: possible
Info: The maintainer address does not have whitespace between the name
 and the email address.

Tag: maintainer-address-is-on-localhost
Severity: important
Certainty: certain
Info: The maintainer address includes localhost(.localdomain), which is
 an invalid e-mail address.
Ref: policy 5.6.2

Tag: uploader-name-missing
Severity: important
Certainty: certain
Info: The uploader field seems to contain just an email address. It must
 contain the package uploader's name and email address.
Ref: policy 5.6.2

Tag: uploader-address-missing
Severity: important
Certainty: certain
Info: The uploader field should contain the package uploader's name and
 email address, with the name followed by the address inside angle
 brackets (&lt; and &gt;).  The address seems to be missing.
Ref: policy 5.6.2

Tag: uploader-address-malformed
Severity: important
Certainty: certain
Info: The uploader field could not be parsed according to the rules in
 the Policy Manual.
Ref: policy 5.6.2

Tag: uploader-not-full-name
Severity: normal
Certainty: possible
Info: The "name" part of this uploader field is just one word, so it
 might not be a full name.

Tag: uploader-address-looks-weird
Severity: normal
Certainty: possible
Info: The uploader address does not have whitespace between the name
 and the email address.

Tag: uploader-address-is-on-localhost
Severity: important
Certainty: certain
Info: The uploader address includes localhost(.localdomain), which is
 an invalid e-mail address.
Ref: policy 5.6.2

Tag: wrong-debian-qa-address-set-as-maintainer
Severity: important
Certainty: certain
Info: Orphaned packages should no longer have the address
 &lt;debian-qa@lists.debian.org&gt; in the Maintainer field.
 .
 The correct Maintainer field for orphaned packages is
 Debian QA Group &lt;packages@qa.debian.org&gt;.
Ref: devref 5.9.4

Tag: wrong-debian-qa-group-name
Severity: important
Certainty: certain
Info: Orphaned packages should have "Debian QA Group
 &lt;packages@qa.debian.org&gt;" in the maintainer field.
Ref: devref 5.9.4

Tag: no-human-maintainers
Severity: normal
Certainty: possible
Info: The Maintainer address for this package is a mailing list and there
 are no Uploaders listed.  Team-maintained packages should list the human
 maintainers in the Uploaders field.
Ref: devref 5.12

Tag: no-source-field
Severity: serious
Certainty: certain
Info: The package does not have a "Source:" field in its control file.
Ref: policy 5.2

Tag: source-field-does-not-match-pkg-name
Severity: serious
Certainty: certain
Info: The source package's filename is not the same as the name given
 in its Source field.  The Source field should name the package.
Ref: policy 5.6.1

Tag: source-field-malformed
Severity: important
Certainty: certain
Info: In a binary package, the Source field should identify the source
 package from which the package was compiled.  It should be the
 source package name, optionally followed by a version number
 between parentheses.
Ref: policy 5.6.1

Tag: essential-in-source-package
Severity: important
Certainty: certain
Info: This field should only appear in binary packages.
Ref: policy 5.6.9
 
Tag: essential-no-not-needed
Severity: normal
Certainty: certain
Info: Having "Essential: no" is the same as not having the field at all,
 so it just makes the Packages file longer with no benefit.
Ref: policy 5.6.9

Tag: unknown-essential-value
Severity: important
Certainty: certain
Info: The only valid values for the Essential field are yes and no.
Ref: policy 5.6.9

Tag: no-section-field
Severity: normal
Certainty: certain
Info: The package does not have a "Section:" field in its control file.
 .
 The field is mandatory for source packages and optional for binary
 packages, which use the source package's value as default is nothing
 else is specified.
Ref: policy 5.3

Tag: unknown-section
Severity: normal
Certainty: certain
Info: The "Section:" field in this package's control file is not one of
 the sections in use on the ftp archive.  Valid sections are currently
 admin, comm, cli-mono, database, debug, devel, doc,
 editors, electronics, embedded, fonts, games, gnome, gnu-r,
 gnustep, graphics, hamradio, haskell, httpd, interpreters,
 java, kde, libdevel, libs, lisp, localization, kernel, mail,
 math, misc, net, news, ocaml, oldlibs, otherosfs, perl,
 php, python, ruby, science, shells, sound, tex, text,
 utils, vcs, video, web, x11, xfce, zope.
 .
 The section name should be preceded by "non-free/" if the package
 is in the non-free archive area, and by "contrib/" if the package
 is in the contrib archive area.
Ref: policy 2.4

Tag: section-is-dh_make-template
Severity: important
Certainty: certain
Info: The "Section:" field in this package's control file is set to
 unknown.  This is not a valid section, and usually means a dh_make
 template control file was used and never modified to set the correct
 section.
Ref: policy 2.4

Tag: wrong-section-for-udeb
Severity: normal
Certainty: certain
Info: udeb packages should have "Section: debian-installer".

Tag: no-priority-field
Severity: normal
Certainty: certain
Info: The package does not have a "Priority:" field in its control file.
 .
 The Priority field can be included in a binary package by passing
 the -ip or -isp flags to dpkg-gencontrol when building the package.
 The field is optional in binary packages.
Ref: policy 5.3

Tag: unknown-priority
Severity: important
Certainty: certain
Info: The "Priority:" field in this package's control file is not one of
 the priorities defined in the Policy Manual.
Ref: policy 2.5

Tag: superfluous-clutter-in-homepage
Severity: normal
Certainty: certain
Info: The "Homepage:" field in this package's control file contains
 superfluous markup around the URL, like enclosing &lt; and &gt;.
 This is unnecessary and needlessly complicates using this information.
Ref: policy 5.6.23

Tag: bad-homepage
Severity: normal
Certainty: certain
Info: The "Homepage:" field in this package's control file does not
 contain a valid absolute URL. Most probably you forgot to specify
 the scheme (e.g. http).

Tag: no-homepage-field
Severity: pedantic
Certainty: possible
Info: This non-native package lacks a <tt>Homepage</tt> field.  If the
 package has an upstream home page that contains useful information or
 resources for the end user, consider adding a <tt>Homepage</tt> control
 field to <tt>debian/control</tt>.
Ref: policy 5.6.23

Tag: homepage-for-cpan-package-contains-version
Severity: minor
Certainty: certain
Info: The Homepage field for this package points to CPAN and the URL
 includes the version.  It's better to link to the unversioned CPAN page
 so that the URL doesn't have to be updated for each new release.  For
 example, use:
 .
   http://search.cpan.org/~samtregar/HTML-Template/
 .
 not:
 .
   http://search.cpan.org/~samtregar/HTML-Template-2.9/

Tag: obsolete-field
Severity: important
Certainty: certain
Info: This field is listed in the Policy Manual as obsolete and
 not-to-be-present in any package.
Ref: policy D.2.6

Tag: unknown-field-in-dsc
Severity: minor
Certainty: certain
Info: See the Policy Manual for a list of the possible fields in
 a source package control file.
Ref: policy 5.4

Tag: unknown-field-in-control
Severity: minor
Certainty: possible
Info: See the Policy Manual for a list of the possible fields in
 a binary package control file.
 .
 In udeb packages the fields pre-depends, conflicts, essential and
 suggests are disallowed, but they can contain the new fields
 subarchitecture and installer-menu-item.
Ref: policy 5.3 

Tag: multiline-field
Severity: important
Certainty: certain
Info: Most control fields must have only a single line of data.
Ref: policy 5.1

Tag: alternates-not-allowed
Severity: important
Certainty: certain
Info: Only the "Depends", "Recommends", "Suggests" and "Pre-Depends"
 fields may specify alternate dependencies using the "|" symbol.
Ref: policy 7.1

Tag: versioned-provides
Severity: important
Certainty: certain
Ref: policy 7.1
Info: The "Provides" field may not specify a version range.

Tag: obsolete-relation-form
Ref: policy 7.1
Severity: normal
Certainty: certain
Info: The forms "&lt;" and "&gt;" mean "&lt;=" and "&gt;=", not "&lt;&lt;"
 and "&gt;&gt;" as one might expect.  For that reason these forms are
 obsolete, and should not be used in new packages.  Use the longer forms
 instead.

Tag: bad-version-in-relation
Ref: policy 5.6.12
Severity: important
Certainty: certain
Info: The version number used in this relationship does not match the
 defined format of a version number.

Tag: package-relation-with-self
Severity: normal
Certainty: possible
Info: The package declares a relationship with itself.  This is not very
 useful, except in the case of a package Conflicting with itself, if its
 package name doubles as a virtual package.

Tag: bad-relation
Severity: important
Certainty: certain
Info: The package declares a relationship that could not be parsed according
 to the rules given in the Policy Manual.
Ref: policy 7.1

Tag: new-essential-package
Severity: important
Certainty: possible
Info: This package has the Essential flag set.  New Essential packages
 are sufficiently rare that it seems worth warning about.  They should
 be discussed on debian-devel first.
Ref: policy 3.8

Tag: doc-package-depends-on-main-package
Severity: normal
Certainty: possible
Info: The name of this package suggests that it is a documentation package.
 It is usually not desirable for documentation packages to depend on the
 packages they document, because users may want to install the docs before
 they decide whether they want to install the package.  Also, documentation
 packages are often architecture-independent, so on other architectures
 the package on which it depends may not even exist.

Tag: depends-on-obsolete-package
Severity: important
Certainty: possible
Info: The package depends on a package that has been superseded.
 If the superseded package is part of an ORed group, it should not be
 the first package in the group.

Tag: ored-depends-on-obsolete-package
Severity: minor
Certainty: possible
Info: The package depends on an ORed group of packages which includes
 a package that has been superseded.

Tag: build-depends-on-obsolete-package
Severity: important
Certainty: possible
Info: The package build-depends on a package that has been superseded.
 If the superseded package is part of an ORed group, it should not be
 the first package in the group.

Tag: ored-build-depends-on-obsolete-package
Severity: minor
Certainty: possible
Info: The package build-depends on an ORed group of packages which includes
 a package that has been superseded.

Tag: depends-on-old-emacs
Severity: normal
Certainty: possible
Info: The package lists an old version of Emacs as its first dependency.
 It should probably be updated to support the current version of Emacs
 in the archive and then list that version first in the list of Emacs
 flavors it supports.
 .
 If the package intentionally only supports older versions of Emacs (if,
 for example, it was included with later versions of Emacs), add a lintian
 override.

Tag: depends-on-x-metapackage
Severity: important
Certainty: certain
Info: Packages that are not themselves metapackages must not depend on X
 Window System metapackages.
 .
 The metapackages xorg, xorg-dev, x-window-system, x-window-system-dev, and
 x-window-system-core exist only for the benefit of users and dependencies
 for other metapackages and should not be used in regular package
 dependencies.

Tag: build-depends-on-x-metapackage
Severity: important
Certainty: certain
Info: Packages must not build-depend on X Window System metapackages.
 .
 The metapackages xorg, xorg-dev, x-window-system, x-window-system-dev, and
 x-window-system-core exist only for the benefit of users and should not
 be used in package build dependencies.

Tag: depends-on-essential-package-without-using-version
Severity: important
Certainty: certain
Ref: policy 3.5
Info: The package declares a depends on an essential package, e.g. dpkg,
 without using a versioned depends.  Packages do not need to depend on
 essential packages; essential means that they will always be present.
 The only reason to list an explicit dependency on an essential package
 is if you need a particular version of that package, in which case the
 version should be given in the dependency.

Tag: build-depends-on-essential-package-without-using-version
Severity: important
Certainty: certain
Ref: policy 4.2
Info: The package declares a build-depends on an essential package, e.g. dpkg,
 without using a versioned depends.  Packages do not need to build-depend on
 essential packages; essential means that they will always be present.
 The only reason to list an explicit dependency on an essential package
 is if you need a particular version of that package, in which case the
 version should be given in the dependency.

Tag: virtual-package-depends-without-real-package-depends
Severity: normal
Certainty: possible
Info: The package declares a depends on a virtual package without listing a
 real package as an alternative first.
 .
 If this package could ever be a build dependency, it should list a real
 package as the first alternative to any virtual package in its Depends.
 Otherwise, the build daemons will not be able to provide a consistent
 build environment.
 .
 If it will never be a build dependency, this isn't necessary, but you may
 want to consider doing so anyway if there is a real package providing
 that virtual package that most users will want to use.

Tag: invalid-arch-string-in-source-relation
Severity: important
Certainty: possible
Ref: policy 5.6.8
Info: The architecture string in the source relation does not follow policy.
 A common cause of this is a comma in the arch, i.e. [i386, m68k], it should
 be [i386 m68k].

Tag: depends-on-build-essential-package-without-using-version
Severity: important
Certainty: certain
Ref: policy 4.2
Info: The package declares a depends on a build essential package without
 using a versioned depends.  Packages do not have to build-depend on any
 package included in build-essential.  It is the responsibility of anyone
 building packages to have all build-essential packages installed.  The
 only reason for an explicit dependency on a package included in
 build-essential is if a particular version of that package is required,
 in which case the dependency should include the version.

Tag: package-depends-on-an-x-font-package
Severity: important
Certainty: certain
Info: Packages must not depend on X Window System font packages.
 .
 If one or more of the fonts so packaged are necessary for proper operation
 of the package with which they are associated the font package may be
 Recommended; if the fonts merely provide an enhancement, a Suggests
 relationship may be used.
Ref: policy 11.8.5

Tag: build-depends-indep-without-arch-indep
Severity: important
Certainty: certain
Ref: policy 7.7
Info: The control file specifies source relations for architecture-independent
 packages, but no architecture-independent packages are built.

Tag: build-depends-without-arch-dep
Severity: minor
Certainty: possible
Ref: policy 7.7
Info: The control file lists the given package in Build-Depends, but no
 architecture-dependent packages are built. If all the packages built are
 architecture-independent, the only packages that should be listed in
 Build-Depends are those required to run the clean target (such as
 debhelper if you use dh_clean). Other build dependencies should be listed
 in Build-Depends-Indep instead.

Tag: clean-should-be-satisfied-by-build-depends
Severity: important
Certainty: certain
Ref: policy 7.7
Info: The specified package is required to run the clean target of
 <tt>debian/rules</tt> and therefore must be listed in Build-Depends, not
 Build-Depends-Indep, even if no architecture-dependent packages are
 built.

Tag: missing-build-dependency
Severity: important
Certainty: certain
Ref: policy 4.2
Info: The package doesn't specify a build dependency on a package that is
 used in <tt>debian/rules</tt>.
 .
 lintian intentionally does not take into account transitive dependencies.
 Even if the package build-depends on some package that in turn
 build-depends on the needed package, an explicit build dependency should
 be added.  Otherwise, a latent bug is created that will appear without
 warning if the other package is ever updated to change its dependencies.
 Even if this seems unlikely, please always add explicit build
 dependencies on every non-essential, non-build-essential package that is
 used directly during the build.

Tag: missing-python-build-dependency
Severity: important
Certainty: certain
Ref: policy 4.2
Info: The package appears to use Python as part of its build process in
 <tt>debian/rules</tt> but doesn't depend on Python.
 .
 Normally, packages that use Python as part of the build process should
 build-depend on one of python, python-all, python-dev, or python-all-dev
 depending on whether they support multiple versions of Python and whether
 they're building modules or only using Python as part of the package
 build process.  Packages that depend on a specific version of Python may
 build-depend on the appropriate pythonX.Y or pythonX.Y-dev package
 instead.

Tag: missing-dh_python-build-dependency
Severity: important
Certainty: certain
Ref: dh_python(1)
Info: The package runs dh_python in <tt>debian/rules</tt> but doesn't
 build-depend on python or python-dev. dh_python requires
 <tt>/usr/bin/python</tt> to run, so packages using dh_python must
 build-depend on python (or python-dev or python-all-dev, which in turn
 depend on python), even if they don't otherwise need Python to build.

Tag: build-conflicts-with-build-dependency
Severity: important
Certainty: certain
Ref: policy 7.7
Info: The package build-conflicts with a package that it also
 build-depends on.

Tag: package-has-a-duplicate-build-relation
Severity: normal
Certainty: possible
Info: The package declares the given build relations on the same package
 in either Build-Depends or Build-Depends-Indep, but the build relations
 imply each other and are therefore redundant.

Tag: build-depends-on-1-revision
Severity: normal
Certainty: possible
Info: The package declares a build dependency on a version of a package
 with a -1 Debian revision such as "libfoo (&gt;= 1.2-1)".  Such a
 dependency will not be satisfied by a backport of libfoo 1.2-1 and
 therefore makes backporting unnecessarily difficult.  Normally, the -1
 version is unneeded and a dependency such as "libfoo (&gt;= 1.2)" would
 be sufficient.  If there was an earlier -0.X version of libfoo that would
 not satisfy the dependency, use "libfoo (&gt;= 1.2-1~)" instead.

Tag: needlessly-depends-on-awk
Severity: important
Certainty: certain
Info: The package seems to declare a relation on awk. awk is a virtual
 package, but it is special since it's de facto essential. If you don't
 need to depend on a specific version of awk (which wouldn't work anyway,
 as dpkg doesn't support versioned provides), you should remove the
 dependency on awk.

Tag: package-depends-on-multiple-libstdc-versions
Severity: important
Certainty: possible
Info: The package seems to declare several relations to a libstdc version.
 This is not only sloppy but in the case of libraries, it may well break
 the runtime execution of programs.

Tag: package-depends-on-multiple-tcl-versions
Severity: important
Certainty: possible
Info: The package seems to declare several relations to a tcl version.
 This is not only sloppy but in the case of libraries, it may well break
 the runtime execution of programs.

Tag: package-depends-on-multiple-tclx-versions
Severity: important
Certainty: possible
Info: The package seems to declare several relations to a tclx version.
 This is not only sloppy but in the case of libraries, it may well break
 the runtime execution of programs.

Tag: package-depends-on-multiple-tk-versions
Severity: important
Certainty: possible
Info: The package seems to declare several relations to a tk version.
 This is not only sloppy but in the case of libraries, it may well break
 the runtime execution of programs.

Tag: package-depends-on-multiple-tkx-versions
Severity: important
Certainty: possible
Info: The package seems to declare several relations to a tkx version.
 This is not only sloppy but in the case of libraries, it may well break
 the runtime execution of programs.

Tag: package-depends-on-multiple-libpng-versions
Severity: important
Certainty: possible
Info: The package seems to declare several relations to a libpng version.
 This is not only sloppy but in the case of libraries, it may well break
 the runtime execution of programs.

Tag: depends-on-libdb1-compat
Severity: important
Certainty: certain
Info: The package seems to declare a relation on libdb1-compat.
 This library exists for compatibility with applications built against
 glibc 2.0 or 2.1. There is intentionally no corresponding development
 package. Do not link new applications against this library!

Tag: depends-on-python-minimal
Severity: important
Certainty: certain
Info: The python-minimal package (and versioned variants thereof) exists
 only to possibly become an Essential package.  Depending on it is always
 an error since it should never be installed without python.  If it
 becomes Essential, there is no need to depend on it, and until then,
 packages that require Python must depend on python.

Tag: depends-exclusively-on-makedev
Severity: normal
Certainty: certain
Info: This package depends on makedev without a udev alternative.  This
 probably means that it doesn't have udev rules and relies on makedev to
 create devices, which won't work if udev is installed and running.
 Alternatively, it may mean that there are udev rules, but udev was not
 added as an alternative to the makedev dependency.

Tag: dbg-package-missing-depends
Severity: normal
Certainty: certain
Info: The given binary package has a name of the form of "X-dbg", indicating it
 contains detached debugging symbols for the package X.  If so, it should
 depend on the corresponding package, generally with (= ${binary:Version})
 since the debugging symbols are only useful with the binaries created by
 the same build.
 .
 If this package provides debugging symbols for multiple other
 packages, it should normally depend on all of those packages as
 alternatives.  In other words, <tt>pkga (= ${binary:Version}) | pkgb (=
 ${binary:Version)</tt> and so forth.

Tag: conflicts-with-dependency
Severity: important
Certainty: certain
Ref: policy 7.4
Info: The package seems to conflict with one of its dependencies,
 recommendations, or suggestions by listing it in Conflicts or Breaks.

Tag: breaks-without-version
Severity: normal
Certainty: possible
Ref: policy 7.3
Info: This package declares a Breaks relationship with another package
 that has no version number.  Normally, Breaks should be used to indicate
 an incompatibility with a specific version of another package, or with
 all versions predating a fix.  If the two packages can never be installed
 at the same time, Conflicts should normally be used instead.

Tag: bad-menu-item
Severity: important
Certainty: certain
Info: The field Installer-Menu-Item should only contain positive integer
 values.

Tag: redundant-origin-field
Severity: normal
Certainty: certain
Info: You use the Origin field though the field value is the default (Debian).
 In this case the field is redundant and should be removed.

Tag: binary-nmu-uses-old-version-style
Severity: normal
Certainty: certain
Ref: devref 5.10.2.1
Info: The version number of a binary NMU should be formed by appending
 <tt>+b</tt> and a digit to the source version.  This version scheme is
 special-cased by the archive software.  The -x.x.x version number style
 should no longer be used.

Tag: binary-nmu-debian-revision-in-source
Severity: normal
Certainty: certain
Ref: devref 5.10.2.1
Info: The version number of your source package ends in +b and a number or
 has a Debian revision containing three parts.  These version numbers are
 used by binary NMUs and should not be used as the source version.  (The
 +b form is the current standard; the three-part version number now
 obsolete.)

Tag: dfsg-version-in-native-package
Severity: normal
Certainty: certain
Info: The version number of this package contains "dfsg", but it's a
 native package.  "dfsg" is conventionally used in the upstream version of
 packages that are repackaged for Debian Free Software Guidelines
 compliance reasons.  The convention doesn't make sense in native
 packages.

Tag: dfsg-version-with-period
Severity: minor
Certainty: possible
Info: The version number of this package contains ".dfsg", probably in a
 form like "1.2.dfsg1".  There is a suble sorting problem with this
 version method: 1.2.dfsg1 is considered a later version than 1.2.1.  If
 upstream adds another level to its versioning, finding a good version
 number for the next upstream release will be awkward.
 .
 Upstream may never do this, in which case this isn't a problem, but it's
 normally better to use "+dfsg" instead (such as "1.2+dfsg1").  "+" sorts
 before ".", so 1.2 &lt; 1.2+dfsg1 &lt; 1.2.1 as normally desired.

Tag: dfsg-version-misspelled
Severity: minor
Certainty: certain
Info: The version number of this package contains "dsfg".  You probably
 meant "dfsg", the conventional marker for upstream packages that are
 repackaged for Debian Free Software Guidelines compliance reasons.

Tag: redundant-bugs-field
Severity: normal
Certainty: certain
Info: You use the Bugs field though the field value is the default 
 (debbugs://bugs.debian.org/). In this case the field is redundant and
 should be removed.

Tag: build-depends-on-build-essential
Info: You depend on the build-essential package, which is only a
Severity: important
Certainty: certain
Ref: policy 7.7
 meta-package depending on build tools that have to be installed in all
 build environments.

Tag: malformed-python-version
Severity: important
Certainty: certain
Ref: python-policy 2.3
Info: The Python-Version control field is not in one of the valid
 formats.  It should be in one of the following formats:
 .
     all
     current
     current, &gt;= X.Y
     &gt;= X.Y
     &gt;= A.B, &lt;&lt; X.Y
     A.B, X.Y
 .
 (One or more specific versions may be listed with the last form.)  A.B
 and X.Y should be Python versions.

Tag: old-versioned-python-dependency
Severity: normal
Certainty: certain
Info: This package appears to be an architecture-independent Python module
 but has a dependency on a version of python less than a particular
 version, doesn't use python-support and no Python-Version control field.
 This normally means that the package isn't using the current Python
 policy; most architecture-independent Python packages will work with any
 future version of Python if they follow the new policy.
 .
 If this package really does require only a particular range of Python
 versions and uses python-central, add a Python-Version control field (as
 described in 2.3 of the Python policy) to resolve this warning.

Tag: malformed-dm-upload-allowed
Severity: important
Certainty: certain
Ref: http://www.debian.org/vote/2007/vote_003
Info: The Dm-Upload-Allowed field in this package is set to something
 other than "yes".  The only standardized value for this field in the
 Debian GR is "yes" and other values (including capitalization variants)
 may not work as expected.

Tag: wrong-section-according-to-package-name
Severity: normal
Certainty: certain
Info: This package has a name suggesting that it belongs to a section
 other than the one it is currently categorized in.

Tag: debug-package-should-be-priority-extra
Severity: normal
Certainty: certain
Info: This package has a name suggesting that it contains detached
 debugging symbols.  If so, it should have priority "extra" since users
 normally do not need such packages.

Tag: maintainer-also-in-uploaders
Severity: minor
Certainty: certain
Info: The maintainer value also appears on the <tt>Uploaders</tt> field.
 There were some reasons why this was useful when Uploaders support was
 first introduced, but those have long-since been fixed and there is no
 longer any need to list the maintainer in Uploaders.  The duplicate
 information should probably be removed.

Tag: duplicate-uploader
Severity: minor
Certainty: certain
Info: The uploader appears more than once in the <tt>Uploaders</tt>
 field.  The duplicate information should be removed.

Tag: versioned-dependency-satisfied-by-perl
Severity: normal
Certainty: certain
Info: This package declares an unnecessary versioned dependency
 on a package that is also provided by one of the Perl core packages
 (perl, perl-base, perl-modules) with at least the required version.
 .
 As versioned dependencies are not satisfied by provided packages,
 this unnecessarily pulls in a separately packaged newer version
 of the module.
 .
 The recommended way to express the dependency without needless
 complications on backporting packages is to use alternative dependencies.
 The Perl core package should be the preferred alternative and the
 versioned dependency a secondary one.
 .
 Example: perl-modules (&gt;= 5.10.0) | libmodule-build-perl (&gt;= 0.26)
Ref: policy 7.5

Tag: package-superseded-by-perl
Severity: normal
Certainty: certain
Info: This package is also provided by one of the Perl core packages
 (perl, perl-base, perl-modules), and the core version is at least
 as new as this one.
 .
 The package should either be upgraded to a newer upstream version
 or removed from the archive as unnecessary. In the removal case, any
 versioned dependencies on this package must first be changed to include
 the Perl core package (because versioned dependencies are not satisfied
 by provided packages).
 .
 The recommended way to express the dependency without needless
 complications on backporting packages is to use alternative dependencies.
 The Perl core package should be the preferred alternative and the
 versioned dependency a secondary one.
 .
 Example: perl-modules (&gt;= 5.10.0) | libmodule-build-perl (&gt;= 0.26)
Ref: policy 7.5

Tag: vcs-field-uses-not-recommended-uri-format
Severity: minor
Certainty: possible
Info: The VCS-* field uses an URI which doesn't match the recommended
 format, but still looks valid. Examples for not recommended URI formats
 are protocols that require authentication (like SSH). Instead where
 possible you should provide an URI that is accessible for everyone
 without authentication.

Tag: vcs-field-uses-unknown-uri-format
Severity: normal
Certainty: possible
Info: The VCS-* field uses an URI which doesn't match any known format.
 You might have forgotten the protocol before the hostname.