Steve Langasek <vor...@debian.org> writes: > 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. I've added a note to the long description of this tag asking for a bug to be filed against Lintian if anyone ever encounters a need to do things this way, but left the severity at certain. >> 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. That tag is significantly more prone to false positives than checking for the template strings. But see my separate message on this topic; I think you'll agree given what Lintian is now looking for. [ binary-file-compressed-with-upx ] >> 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. Yes, I know Lintian has a check for it, but I've never devised a *test case* for it. In other words, I've never seen or been able to create a package that will trigger it. I suspect doing so would require looking at the magic from file and figuring out what it thinks would make a UPX binary. I think this tag is the equivalent of binary-package-contains-unicorns. > (Oh, but upstream-version-not-numeric? Why should we *force* > maintainers to mangle upstream version numbers to fit this schema?) That one always struck me as weird. Why have a "should" constraint on version numbers? What does that even mean? It seems to me that a version number is a syntax thing: either it's accepted or it isn't. Is there some subtle problem that's solved by mangling the version number to make it numeric? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
