Re: Lintian based autorejects
Steve Langasek <firstname.lastname@example.org> writes:
> I've put together a hand-rolled test package that demonstrates this:
> 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
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
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
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
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>