Bug#879123: glee: source for configure is missing

[Simon McVittie]

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