Re: What is an invalid package?
Felix Lechner <felix.lechner@lease-up.com> writes:
> 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"?
Yes, I think the presence of an invalid control file in the package is the
sort of obvious packaging bug I'm thinking about. There's essentially no
downside in rejecting such packages at the build step, similar to how a
compiler would reject code with a syntax error even in an unused function.
> 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?
Rejecting weird symlinks is a valuable security control, loops make it
hard to test for dangerous symlinks, and I'm dubious that any such
upstream sources exist, so yes, I think that's the correct decision. If
it turns out there are a lot of upstream sources that contain symlink
loops, the decision could be reconsidered, but I doubt that will happen.
> 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?
I think you have misunderstood the scope of that Policy requirement. That
says that packages must not contain control files encoded in another way.
It doesn't mean any specific piece of software is obligated to detect and
reject such packages (although obviously that's helpful to keep bugs out
of the archive). The requirement is on the maintainer.
That said, I certainly wouldn't object to dpkg rejecting packages that
don't use UTF-8 in the debian/changelog entries that are copied into the
*.changes file.
> True, but Lintian is much better equipped to provide context, references
> and other packages so affected.
How much context is required to understand "you are missing mandatory
fields in this control file"? It seems like a straightforward error.
> Plus, we maintain nice explanations that are often superior to dpkg's
> one-liners, which can be hard to spot in typical build logs.
Fatal errors are fairly easy to spot. :) It helps when the build then
immediately stops.
I share your worry about dpkg warnings, and I think it's valuable to
duplicate those in Lintian to make them more visible.
> Also, Lintian can run, at least theoretically, on packages created by
> any tool, although I am not sure there are alternatives to Dpkg.
There aren't. It's possible to cobble something together without it, but
it's fairly explicitly not supported by Policy.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: