Re: Lintian based autorejects
Steve Langasek <vorlon@debian.org> writes:
> Some problems I find with this list:
> E: ftp-master: wrong-file-owner-uid-or-gid
> N:
> N: The user or group ID of the owner of the file is invalid. The owner
> N: user and group IDs must be in the set of globally allocated IDs,
> N: because other IDs are dynamically allocated and might be used for
> N: varying purposes on different systems, or are reserved. The set of the
> N: allowed, globally allocated IDs consists of the ranges 0-99,
> N: 64000-64999 and 65534.
> N:
> N: Refer to Debian Policy Manual section 9.2 (Users and groups) for
> N: details.
> N:
> N: Severity: serious, Certainty: certain
> Policy 9.2 does /not/ prohibit shipping files with owners outside these
> ranges; it prohibits relying on user or group IDs outside these ranges
> being static, but there doesn't appear to be anything in Policy that
> prohibits creating the user in the package preinst and then unpacking
> the package such that ownership is applied by /name/. (Unless I'm
> mistaken, this is precisely what dpkg does.)
I wasn't aware of this. Do you know of a package that does this? And can
we confirm that dpkg does handle this correctly (in other words, that the
UID is ignored if the package is unpacked when the symbolic owner or group
already exists on the system with a different UID)?
> E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate
> N:
> N: There is "Upstream Author(s)" in your copyright file. This was most
> N: likely a remnant from the dh_make template.
> N:
> N: There's either one upstream author, in which case you should remove
> N: the "(s)", or there are several upstream authors, in which case you
> N: should remove the "(" and ")".
> N:
> N: o/~ join us now and carefully edit debian/copyright files! o/~
> N:
> N: Severity: normal, Certainty: certain
> N:
> This one has been mentioned previously in the thread. Yes, it's a
> blemish in the package to list "Upstream Author(s)", but the lintian
> maintainers have correctly marked this as being of "normal" severity.
> We should not be blocking packages from the archive for such
> low-severity issues; please drop this check.
Lintian will almost certainly change here to use the other boilerplate of
dh-make as opposed to keying off of Author(s). Once that's done, I think
it's a fairly reliable indicator that the upstream author section of the
dh-make boilerplate hasn't been edited. Personally, I'm happy to reject
packages on that basis; it seems like the least that we could ask for
maintainers to handle. Policy does require that debian/copyright be
filled out, which is what this is trying to check.
> E: ftp-master: section-is-dh_make-template
> N:
> N: The "Section:" field in this package's control file is set to unknown.
> N: This is not a valid section, and usually means a dh_make template
> N: control file was used and never modified to set the correct section.
> N:
> N: Refer to Debian Policy Manual section 2.4 (Sections) for details.
> N:
> N: Severity: important, Certainty: certain
> Sections in source packages have minimal impact; the section that
> matters is the one specified in the archive override. There's no reason
> that the invalid default value given by dh_make should result in a
> package being rejected, when arbitrary other values for the field would
> not. Please drop this check.
Seems to me like there's no point in asking the ftpmasters to come up with
the source package section name because the package author didn't notice
and set one before the first upload. Although I do agree that if we're
going to make this a mandatory requirement for packages, Policy needs to
be modified accordingly.
> E: ftp-master: binary-file-compressed-with-upx
> N:
> N: Debian does not allow binaries to be compressed by UPX.
> N:
> N: Severity: important, Certainty: certain
> Where is this documented? There's no mention of UPX in Debian Policy,
> and the only mention in the lintian changelog is a 2001 bug about adding
> support for /reading/ UPX executables.
I suspect that this tag has never triggered, at least in the last few
years. I've never devised a test case for it, and I've never seen it
appear in the archive.
> E: ftp-master: copyright-file-is-symlink
> N:
> N: The copyright file /usr/share/doc/<pkg>/copyright must not be a
> N: symbolic link.
> N:
> N: Refer to Debian Policy Manual section 12.5 (Copyright information) for
> N: details.
> N:
> N: Severity: serious, Certainty: certain
> This looks to me like a bug in Policy. Why do we allow
> /usr/share/doc/$pkg to be a symlink, but disallow
> /usr/share/doc/$pkg/copyright as a symlink if it fulfills the same
> constraints? Will follow up on this separately via debian-policy.
This should be discussed on debian-policy, yes. I'm personally rather
annoyed that Ubuntu changed this rule for Ubuntu packages without, at
least that I can recall, any consultation with Debian, but I think it's
probably a reasonable change.
> E: ftp-master: debian-rules-is-symlink
> N:
> N: The file debian/rules is a symlink instead of a regular file. This is
> N: unnecessary and makes package checking and manipulation more
> N: difficult. If the rules file should be available in the source package
> N: under multiple names, make debian/rules the real file and the other
> N: names symlinks to it.
> N:
> N: This problem may have prevented lintian from performing other checks,
> N: leading to undetected changelog errors.
> N:
> N: Severity: normal, Certainty: certain
> Not a requirement that's derived from Policy at all. If you think this
> is important to require for all packages due to the side effect on
> lintian's ability to do further checking, please discuss it on
> debian-policy; in the meantime, please drop.
Whatever is done with this tag should probably also be done with
debian-control-file-is-a-symlink.
> The following checks are also marked as "should" requirements in Debian
> Policy, not "must"s. The ftp team has no authority to escalate these to
> "must" at the archive level. Please drop these checks, and follow the
> procedure for amending Policy if you think they need to be enforced.
> (Several of these changes I might be inclined to second myself, but I
> object to any such checks being enforced in the archive when they have
> not been ratified by the project first.)
> E: ftp-master: html-changelog-without-text-version
> E: ftp-master: upstream-version-not-numeric
> E: ftp-master: build-depends-on-essential-package-without-using-version
> E: ftp-master: depends-on-build-essential-package-without-using-version
> E: ftp-master: build-depends-on-build-essential
> E: ftp-master: no-standards-version-field
> E: ftp-master: invalid-standards-version
invalid-standards-version is a syntax error given the syntax description
of the control file and as such is an implicit must in policy, so I think
that one's fine.
I think all of the rest of these should be upgraded to a must, personally.
Well, build-depends-on-build-essential doesn't actually break anything;
it's just pointless and silly. So possibly not that one.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: