Hi Russ,, On Wed, Jul 1, 2020 at 8:25 PM Russ Allbery <[email protected]> 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
