Bug#778955: lintian: suggest check html <img>s included in package
On 2015-02-24 01:53, Kevin Ryde wrote:
> Niels Thykier <niels@thykier.net> writes:
>>
>> I do have some concerns on the performance front. On some packages,
>> this will be the "second slowest" check taking 10s or more.
>
> Hmm. If html files are usually only moderately common then maybe the
> totality across all packages is acceptable, even if a few packages have
> a lot to check.
>
The maintainer of those packages will still suffer. The greatest
benefit of lintian is that the majority of maintainers run it before
uploading to the archive. If Lintian becomes too slow for them, they
will stop using it.
I realise you cannot add more checks without increasing what needs to
be processed, but I am wary of making packages a lot slower - even if it
is only a few packages.
>> However, it requires that the binaries are built from the same source.
>
> I wondered that. Is it ok to look into arbitrary packages in the lab?
> (Just asking whether they contain a given file, with symlink following.)
>
Main lintian checks themselves are not. Third-party checks may,
although there is no reasonable API for doing it. The reason for this
limitation is the "same source analysis" clause from[1].
>> performance characteristics
>> of using HTML::Parser over the current approach.
>
> I'll see if I can measure. HTML::Parser has some C code, but makes
> callbacks to perl code.
>
Thanks.
>> That could make sense - I am thinking it would make sense to move the
>> privacy breaker checks into the http-check file as well. Currently, it
>> scans all files matching:
>>
>> $fname =~ m,\.(?:x?html?|js|xht|xml|css)$,i
>
> Maybe css and js would have to be treated a little differently but the
> rest yes.
>
>
Indeed, but overall it will hopefully be a win. If this can be used to
reduce the runtime of the files check, we can use some of this to "pay"
for the html.pm check.
Thanks,
~Niels
[1] https://lintian.debian.org/manual/section-1.3.html
Reply to: