Bug#933134: lintian: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi,
On Wed, Jul 31, 2019 at 8:29 AM intrigeri <intrigeri@debian.org> wrote:
>
> I've pushed my current WIP to
> https://salsa.debian.org/intrigeri/lintian/tree/bug933134.
> I'm not sure if/when I'll be able to resume work on it,
> so please don't block on me.
Thank you. I will start with your code when we decide to go with
Dpkg::Changelog::Debian.
> - Your MR introduces yet another debian/changelog parser.
>
> Given the trouble we had with keeping Parse::DebianChangelog somewhat
> working and up-to-date so far, I would argue that relying on existing,
> well-maintained Dpkg::* code, is a safer approach on the long term.
Having converted the Lintian test suite from a custom approach to
TAP::Parser, I share your sentiment about using established, and
tested, third-party packages. I am more tolerant, however, when
duplicating efforts related to Debian---such as analyzing the
changelog. Lintian is supposed to be an independent critic, and there
is a value to, well, being independent.
The changelog parser is also a relatively small piece of code.
A more significant issue is that Dpkg::Changelog::Debian may not offer
the kind of data structures I hope to offer to writers of Lintian
checks. At least, I felt that way when implementing centralized
version parsing as part of the $info data structure for source
packages (MR in preparation) pursuant to this message:
https://lists.debian.org/debian-lint-maint/2019/07/msg00141.html
and based on this code:
https://salsa.debian.org/lintian/lintian/blob/master/checks/source-changelog.pm#L28-84
If it helps us with a decision, I could submit that MR first. Or,
Chris could accept my merge request !234 for now. We could look at
alternatives later. That would immediately resolve #933134, which
prevents the removal of libparse-debianchangelog-perl. (From your bug
filing, it sounded like a priority for the Perl team.) Lintian would
be off no worse than before: We have an old parser that does not use
Dpkg::Changelog::Debian. :)
This last course of action is my favorite. I have so many changes in
the pipeline, it would be far easier for me to adapt Lintian to
Dpkg::Changelog::Debian later than to rebase my branches. I promise to
undertake the integration work, if necessary. Would that be agreeable
to you?
> But it requires more initial work because the API differs slightly,
> and more importantly, the Dpkg::Changelog::Debian parser is stricter,
> so we lose some granularity wrt. error reporting (some syntax errors
> Lintian would previously catch itself later on are now reported as
> syntax errors, as soon as we parse the changelog file).
I am not worried about the amount of work, but about its outcome: As
you acknowledge, Dpkg::Changelog::Debian's lack of granularity may
make it harder to implement distinct tags. That results less detailed
advice on how to improve packages, and is less customer-friendly.
Kind regards,
Felix
Reply to: