On Fri, 20 Oct 2017 at 14:36:06 +0200, Markus Koschany wrote: > If you insist on severity > serious for such a problem, then bug reports with the same severity > should be filed against packages > > a) that do not recreate their build system at build time > b) all packages that contain a prebuilt object without corresponding > source, even when they are not used to build the package, or used at > runtime (like .dll and .exe files)
I don't think those are the same thing at all, and I think trying to equate them clouds the issue. If we have a generated/derived file in source packages, there are three possibilities: 1. Source code is provided, and we regenerate the generated file from it (for example, if the generated file is configure, we have configure.ac and we run dh-autoreconf; or if the generated file is a binary, we have the C/C++/etc. source code and we recompile it from source). For files that we actually use, this is the ideal case, and should happen if it's practical to do so (it isn't always). 2. Source code is provided, but we don't rebuild the derived file from it (for example, we have configure.ac, but we use the pre-generated configure script instead of running autoreconf to regenerate configure; or we have source code, but we use a prebuilt binary instead of rebuilding it). This is normally considered to be a bug, whose severity depends on the circumstances: - For prebuilt binary executables, this is usually RC, because we usually can't know whether the source actually corresponds to the binary, we can't meaningfully audit the binary, we can't fix its bugs if it has them, and if we can't audit the binary then we shouldn't trust it to be non-malicious. - For sort-of-human-readable and sort-of-bug-fixable derived files like configure, I think there's consensus that this is a bug, but usually not a release-critical one; and sometimes regenerating the generated file isn't not practical, so we tolerate that bug because the alternative (not shipping the software) would be worse. 3. We don't have the source code from which it was generated. I think there's consensus that this isn't DFSG-compliant, because DFSG ยง2 says we will ship source code (for packages in main and contrib). The definition of source code sometimes gets very subjective, but Debian usually borrows the "preferred form for modification" concept from the GPL as a working definition of source code, and Autoconf-generated configure scripts are rarely that (more on that later). Talking about whether or not dh-autoreconf is run is to do with the difference between what I've called (1.) and (2.) above. I think the objection that others are raising in this thread is more about whether the source code is present *at all*, which is the difference between (2.) and (3.). > a) that do not recreate their build system at build time That's usually my (2.) above, and I think there is consensus that this is normally a *non-release-critical* bug. We don't solve all non-release-critical bugs, and software with non-release-critical bugs can stay in Debian. Running dh-autoreconf is best-practice (I wouldn't want to claim that I can audit a generated configure script for malicious code, but if I replace it with a re-generated version then I don't have to, so this appeals to my sense of both responsibility and laziness). However, I recognise that it isn't always feasible. I don't think any of the participants in this thread are claiming that not running dh-autoreconf is a RC bug. IMO it could be anywhere from wishlist to important, depending on how much pain it's causing for continued maintenance. > b) all packages that contain a prebuilt object without corresponding > source, even when they are not used to build the package, or used at > runtime (like .dll and .exe files) That's my (3.) above, and I think there is consensus that it is a release-critical bug. We remove these objects when we find them. (If I am wrong about that, then I can stop repacking the Quake series of game engines to exclude prebuilt Windows DLLs... but I would not want to do that without approval from the ftp team, and the ftp team seem highly unlikely to give that approval.) For a configure script, I agree that the situation is less clear-cut than for a prebuilt binary object. A derived file can sometimes be *a* preferred form for modification (for instance if a reasonable person could be expected to generate a skeleton source file from a template once, but subsequently edit the generated file and never regenerate it). However, for Autoconf configure scripts, this would be an exceptional case: Autoconf configure scripts are rarely modified directly, and much more commonly re-generated from configure.ac or configure.in. If there is evidence of the copyright holder treating the generated configure script as the form to be modified (hand-editing it) then it would be reasonable to argue that this is one of those exceptional cases. Otherwise, it seems more likely that this is a file with missing source code. Regards, smcv