Re: Lintian based autorejects
Steve Langasek <vorlon@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: