What is an invalid package? (Was: Checking vs. building packages)
Hi Russ,,
On Wed, Jul 1, 2020 at 8:25 PM Russ Allbery <rra@debian.org> wrote:
>
> dpkg has been picking up basic sanity checks for obvious packaging bugs
Thank you for using such decisive language. My message was exactly
about that. Please allow me to restate the original question: Is the
absence of fields in d/test/control such an "obvious packaging bug"?
> I don't
> think it makes sense to rely on linting to reject invalid packages.
Or, to borrow your alternative wording, is a package with missing
fields in d/tests/control really an "invalid package"?
Your choice of words was so fitting, I adopted them as the subject
header. What is an "invalid package", please?
In Lintian, we certainly have a graduated view.
Similarly, I am not sure that symlink loops in source code are serious
enough for dpkg-source to refuse unpacking (please the open Bug#964111
for details). Must faulty upstream sources, which regularly contain
odd artifacts, now be repackaged?
In a basic inconsistency, dpkg-buildpackage still creates such packages.
I hope we agree that there is a gray area. I am merely asking for clarification.
By comparison, I was stunned when the Dpkg Maintainers refused to
ensure that all *.changes files are UTF-8 encoded, arguably a more
basic and more direct requirement. The last time I checked (which was
prior to the most recent release) dpkg-genchanges simply copied legacy
encodings from d/changelog to *.changes. I was told that Dpkg tries to
change as little as possible.
At the same time, Policy 5.1 states that "All control files must be
encoded in UTF-8." Is that requirement not more binding on Dpkg than
the presence of fields in d/tests/control? In view of the rigor
imposed on d/tests/control, should Dpkg produce *.changes files---one
of its own products---in legacy encoding?
> Linting is optional
True, but Lintian is much better equipped to provide context,
references and other packages so affected. Plus, we maintain nice
explanations that are often superior to dpkg's one-liners, which can
be hard to spot in typical build logs.
Also, Lintian can run, at least theoretically, on packages created by
any tool, although I am not sure there are alternatives to Dpkg.
Kind regards
Felix Lechner
Reply to: