On Sun, Nov 01, 2009 at 01:31:08PM -0800, Russ Allbery wrote: > Steve Langasek <vorlon@debian.org> writes: > > Some problems I find with this list: > > E: ftp-master: wrong-file-owner-uid-or-gid > > 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)? I've put together a hand-rolled test package that demonstrates this: http://people.debian.org/~vorlon/test-package_1_all.deb lintian reports the 'wrong-file-owner-uid-or-gid' error for this package, but you'll see that unpacking it results in a file /usr/share/doc/test-package/dynamically-owned owned by 'dynamic-test' regardless of which UID dynamic-test ends up with. To be honest, the last package I saw making use of such behavior was qmail-src, which is hardly an exemplary package; to land a package with these characteristics in the archive, you would effectively need to both build-depend on and pre-depend on another package which creates the user you need. (And in the case of qmail-src, the packages doing this were never in the archive - they were built on the end-user's system.) Nevertheless, if we're going to prohibit this behavior, that change should be ratified via the consensus-based Policy process. > > E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate > > 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. We already have more correct checks for this, such as copyright-without-copyright-notice. "Upstream Authors" isn't something that's required to be listed anyway; either the authors are the same as the copyright holder and it's redundant with the copyright notice, or they're not the same and listing the authors is a nicety rather than a legal requirement. So while I'm personally annoyed any time I see this boilerplate, I still don't think we should be treating as fatal errors bugs whose real impact is minimal. > > E: ftp-master: section-is-dh_make-template > > 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. Don't the ftpmasters make their own independent judgement on the section field anyway? I don't see how it helps to require the Section field be changed to /some/ other value when there's no guarantee that the new value is valid or correct. It's just one more thing to cause a round-trip for the maintainer. (N.B.: this check would fail even in the case of a package with a pre-existing section override in the archive. What's the sense of that? Let the maintainer get the nag mail after the fact telling them to reconcile the section, instead.) > > 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. /usr/share/lintian/checks/binaries includes a check for it. Really needs to be discussed on debian-policy before it's being made a fatal error. > > E: ftp-master: copyright-file-is-symlink > > 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. Personally, I'm far more annoyed that Ubuntu isn't enforcing the requirement of strict versioned dependencies when symlinking /usr/share/doc. But that's an Ubuntu bug, not something I'm going to try to change in Debian. :) > > 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. That's fair, though I think it's a silly reason to reject a package from the archive. > 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. Except that the impact of *all* of these is incredibly small when the maintainer gets it wrong, and I haven't seen any evidence that these bugs are correlated with the more serious packaging problems we should be concerned with. Should we be concerned about these bugs? Yes, but we have existing methods of addressing them: lintian reporting and filing bugs. And that seems to be working quite well, given how many packages are affected by the tags in the above list: $ wcat http://ftp-master.debian.org/~joerg/lintian/errors \ | grep -E 'html-changelog-without-text-version|upstream-version-not-numeric|build-depends-on-essential-package-without-using-version|depends-on-build-essential-package-without-using-version|build-depends-on-build-essential|no-standards-version-field|invalid-standards-version' \ | cut -f1 | sort -u | wc -l 17 $ So why do we want to use hard rejects for issues that are largely cosmetic? This looks to me like government bureaucracy, not a foundation for improving our OS. Anyway, I'm happy to discuss any of these on debian-policy; as I said, some of them I'm likely to even support promoting to "must". (Oh, but upstream-version-not-numeric? Why should we *force* maintainers to mangle upstream version numbers to fit this schema?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature