Check-Script: fields Author: Marc 'HE' Brockschmidt Abbrev: fld Type: binary, udeb, source Needs-Info: debfiles, index 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", "3.0 (quilt)" or "3.0 (native)". Other package formats are supported by dpkg-source, but they are not allowed in the Debian archive. 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: bad-provided-package-name Severity: serious Certainty: certain Info: A package name should be at least two characters long, must consist of the alphanumerics (lowercase characters only) and "+" "-" and ".", and must start with an alphanumeric character. 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 makes sense if it occurs alone or (in a *.dsc file) together with "all". 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, #626775 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-wildcard-in-binary-package Severity: serious Certainty: certain Info: Architecture wildcards, including the special architecture value "any", do not make sense in a binary package. A binary package must either be architecture-independent or built for a specific architecture. Ref: policy 5.6.8 Tag: unknown-multi-arch-value Severity: serious Certainty: certain Info: The package has an unknown value in its Multi-Arch field. The value must be one of "no", "same", "foreign" or "allowed". Tag: illegal-multi-arch-value Severity: serious Certainty: certain Info: The package is architecture all and has the Multi-Arch same value. . This combination is not allowed by the Multi-Arch specification. Ref: https://wiki.ubuntu.com/MultiarchSpec 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 must contain the package maintainer's name and email address, with the name followed by the address inside angle brackets (< and >). The address seems to be missing. Ref: policy 5.6.2 Tag: maintainer-address-malformed Severity: serious 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-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: serious Certainty: certain Info: The maintainer address includes localhost(.localdomain), which is an invalid e-mail address. Ref: policy 5.6.2 Tag: maintainer-address-causes-mail-loops-or-bounces Severity: serious Certainty: certain Info: The maintainer e-mail address either loops back to itself because it is set to package@packages.debian.org or package@packages.qa.debian.org or references an email address (typically a mailing list) which is known to bounce mails. Policy states: The email address given in the Maintainer control field must accept mail from those role accounts in Debian used to send automated mails regarding the package. This includes non-spam mail from the bug- tracking system. Ref: policy 3.3 Tag: uploader-name-missing Severity: serious 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.3 Tag: uploader-address-malformed Severity: serious Certainty: certain Info: The uploader field could not be parsed according to the rules in the Policy Manual. Ref: policy 5.6.3 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: serious Certainty: certain Info: The uploader address includes localhost(.localdomain), which is an invalid e-mail address. Ref: policy 5.6.3 Tag: uploader-address-causes-mail-loops-or-bounces Severity: serious Certainty: certain Info: The maintainer e-mail address either loops back to itself because it is set to package@packages.debian.org or package@packages.qa.debian.org or references an email address (typically a mailing list) which is known to bounce mails. Policy states: The email address given in the Maintainer control field must accept mail from those role accounts in Debian used to send automated mails regarding the package. This includes non-spam mail from the bug- tracking system. Ref: policy 3.3 Tag: wrong-debian-qa-address-set-as-maintainer Severity: important Certainty: certain Info: Orphaned packages should no longer have the address <debian-qa@lists.debian.org> in the Maintainer field. . The correct Maintainer field for orphaned packages is Debian QA Group <packages@qa.debian.org>. Ref: devref 5.9.4 Tag: wrong-debian-qa-group-name Severity: important Certainty: certain Info: Orphaned packages should have "Debian QA Group <packages@qa.debian.org>" in the maintainer field. Ref: devref 5.9.4 Tag: no-human-maintainers Severity: serious Certainty: possible Info: The Maintainer address for this package is a mailing list and there are no Uploaders listed. Team-maintained packages must list the human maintainers in the Uploaders field. Ref: policy 3.3, 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: serious Certainty: certain Info: In debian/control or a .dsc file, the Source field must contain only the name of the source package. In a binary package, the Source field may also optionally contain the version number of the corresponding source package in parentheses. . Source package names must consist only of lowercase letters, digits, plus and minus signs, and periods. They must be at least two characters long and must start with an alphanumeric character. 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: serious 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 < and >. 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). . This tag is also triggered if the scheme is not known by Lintian. . Please file a bug against Lintian, if this tag is triggered for a valid homepage URL. Tag: no-homepage-field Severity: pedantic Certainty: possible Info: This non-native package lacks a Homepage field. If the package has an upstream home page that contains useful information or resources for the end user, consider adding a Homepage control field to debian/control. 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 "<" and ">" mean "<=" and ">=", not "<<" and ">>" 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: serious 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-metapackage Severity: important Certainty: possible Info: This package is one of the packages that Lintian believes is a metapackage: a package that exists for the convenience of users or installers to install a set of related packages. Packages that are not themselves metapackages must not depend on metapackages, since this may prevent the user from removing portions of the package set they don't need. Tag: build-depends-on-metapackage Severity: important Certainty: certain Info: Packages must not build-depend on metapackages. . Metapackages such as 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: build-depends-on-non-build-package Severity: important Certainty: certain Info: The package declares a build dependency on a package that is not appropriate for build dependencies, usually because it's only for interactive use or cannot be correctly installed in a build environment. See the description or documentation of the package for more information. 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 includes an unknown architecture. This may be a typo, or it may be an architecture that dpkg doesn't know about yet. A common problem is incorrectly separating architectures with a comma, such as [i386, m68k]. Architectures are separated by spaces; this should instead be [i386 m68k]. Tag: conflicting-negation-in-source-relation Severity: serious Certainty: certain Ref: policy 7.1 Info: The architecture string in this source relation has some negated architectures (prepended by !) and others that are not negated. This is not permitted by Policy. Either all architectures must be negated or none of them may be. 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-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 (>= 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 (>= 1.2)" would be sufficient. If there was an earlier -0.X version of libfoo that would not satisfy the dependency, use "libfoo (>= 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, pkga (= ${binary:Version}) | pkgb (= ${binary:Version}) 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, policy 7.4, #605744 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. . Note this tag can also be issued, if a package has been split into two completely new ones. In this case, this package is missing a Replaces on the old package. Tag: conflicts-with-version Severity: normal Certainty: wild-guess Ref: policy 7.4 Info: An earlier-than version clause is normally an indication that Breaks should be used instead of Conflicts. Breaks is a weaker requirement that provides the package manager more leeway to find a valid upgrade path. Conflicts should only be used if two packages can never be unpacked at the same time, or for some situations involving virtual packages (where a version clause is not appropriate). In particular, when moving files between packages, use Breaks plus Replaces, not Conflicts plus Replaces. 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 +b 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 subtle 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 < 1.2+dfsg1 < 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 metapackage depending on build tools that have to be installed in all build environments. Severity: important Certainty: certain Ref: policy 7.7 Tag: depends-on-packaging-dev Info: You depend/recommend/build-depend on packaging-dev, which is only a metapackage to install common packages needed for packaging. Severity: normal Certainty: certain 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, >= X.Y >= X.Y >= A.B, << 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: 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: possible 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 Uploaders 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 Uploaders 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 package should be the preferred alternative and the versioned dependency a secondary one. . Example: perl (>= 5.10.0) | libmodule-build-perl (>= 0.26) . An exception to this is when the dependency is only satisfied in a version of perl in experimental. In this case, the dependency on perl should come second. . Example: libextutils-parsexs-perl (>= 2.210000) | perl (>= 5.14) 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 package should be the preferred alternative and the versioned dependency a secondary one. . Example: perl (>= 5.10.0) | libmodule-build-perl (>= 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. Tag: lib-recommends-documentation Severity: normal Certainty: possible Info: The given package appears to be a library package, but it recommends a documentation package. Doing this can pull in unwanted (and often large) documentation packages since recommends are installed by default and library packages are pulled by applications that use them. Users usually only care about the library documentation if they're developing against the library, not just using it, so the development package should recommend the documentation instead. If there is no development package (for modules for scripting languages, for example), consider Suggests instead of Recommends. Tag: build-depends-on-python-dev-with-no-arch-any Severity: normal Certainty: possible Info: The given package appears to have a Python development package (python-dev, python-all-dev or pythonX.Y-dev) listed in its Build-Depends or Build-Depends-Indep fields, but only "Architecture: all" packages are built by this source package. Python applications and modules do not usually require those dev packages, so you should consider removing them in favour of python, python-all or pythonX.Y. . If you are building a Python extension instead, you should have development packages listed in Build-Depends, but normally there should be at least one Architecture: any package. Tag: build-depends-on-specific-java-doc-package Severity: normal Certainty: certain Info: The given package declares a build dependency on either openjdk- X-doc or classpath-doc instead of using default-jdk-doc. default-jdk-doc provides a symlink to the API via /usr/share/default-jdk-doc/api. Tag: depends-on-specific-java-doc-package Severity: normal Certainty: certain Info: The package should use default-jdk-doc instead of classpath-doc or openjdk-X-doc to ease transitions when the providing doc package is replaced (e.g. openjdk-6-doc being replaced by openjdk-7-doc). Tag: needless-dependency-on-jre Severity: normal Certainty: possible Info: The package appear to be a Java library and depending on one or more JRE/JDK packages. As of 05 Apr 2010, the Java Policy no longer mandates that Java libraries depend on Java Runtimes. . If the library package ships executables along with the library, then please consider making this an application package or move the binaries to a (new) application package. . If there is otherwise a valid reason for this dependency, please override the tag. Ref: http://packages.qa.debian.org/j/java-common/news/20100405T221415Z.html, #227587 Tag: documentation-package-not-architecture-independent Severity: normal Certainty: certain Info: Documentation packages usually shouldn't carry anything that requires recompiling on various architectures, in order to save space on mirrors. Tag: build-depends-on-versioned-berkeley-db Severity: normal Certainty: possible Info: The package build-depends on a versioned development package of Berkeley DB (libdbX.Y-dev) instead of versionless package (libdb-dev). Unfortunately this prevents binNMUs when default Berkeley DB version changes. . Unless the package absolutely have to depend on specific Berkeley DB version, it should build-depends on libdb-dev. For more information on the upgrade process, please see the references. . The package can usually be made Berkeley DB version agnostic by the following steps: . 1. note the version of Berkeley DB used to compile the package on build time 2. on first install copy the used version to active version 3. on upgrades compare the versions and if they differ do the upgrade procedure . If you are unsure you can contact Berkeley DB maintainer, who would be glad to help. . Should the package have a legitimate reason for using the versioned development package, please add an override. Ref: http://download.oracle.com/docs/cd/E17076_02/html/upgrading/upgrade_process.html Tag: transitional-package-should-be-oldlibs-extra Severity: normal Certainty: possible Ref: #645438 Info: The package appears to be a transitional package, but it is not priority extra and in the oldlibs section. . Using oldlibs/extra assists package managers in handling the transition package correctly.