[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: