Bug#879123: glee: source for configure is missing

[Simon McVittie]

On Fri, 20 Oct 2017 at 16:22:38 +0200, Markus Koschany wrote:
> So you are basically saying that the situation for configure scripts is
> less clear-cut and you tend to acknowledge that this is a bug but
> usually not a release critical one and it also depends on how the
> copyright holder is treating the generated file.

I only partially agree with this summary; I think it's still in
danger of conflating two issues.

I think having both configure and configure.ac in the source tarball,
using upstream's pre-generated configure without re-generating it, but
having its source code present, is usually a bug but not a RC one.
A concrete example from one of my packages: if I'm reading my old
changelog correctly, dbus (<< 1.4.10-1) was buggy in this way, but I
don't think that bug was RC.

However, I think having configure but not configure.ac is usually
a RC bug, due to DFSG §2. (Exceptional case: if upstream genuinely treats
configure as though it was source - hand-editing it, etc. - then I
would consider it to be technically misguided, but DFSG-compliant.)

> What do you make of this specific case now, a modifiable but unused
> configure file in a source package? Would you remove this file from one
> of your packages given the same circumstances? Is this release-critical
> for you?

I would be annoyed to have to take action for something this trivial
(so I can understand why you are annoyed), but yes, I think it's RC and
requires a +dfsg1 tarball.

I wouldn't be in any hurry to fix that bug for prior releases unless
someone in the stable release team felt strongly about it, though -
we shipped it already, and it isn't a copyright violation, only a
DFSG violation (breaking the rules we set for ourselves, but not the law).

> However I do not think the same
> severity is appropriate for Windows files because they are platform
> specific and usually are only there for the convenience of upstream's
> windows users. They waste disk space but do not impair my freedom.

This depends whether those Windows convenience files come with DFSG
source code or not. If they do, fine, we can accept the "dead weight",
just like we don't bother to remove the pre-generated configure from
source packages where we are going to overwrite it with dh-autoreconf
anyway.

If there is no source code, my understanding is that derived files
without source are equally forbidden by the ftp team regardless of
whether they are used in building our binary packages or not. One
justification for this position is that it is not just about your
freedom to modify what will go into the binary package, but also about
recipients of source code via Debian being able to be confident that
everything they receive is equally DFSG-compliant (for example, in
the past I've cross-compiled Debian's libexpat for Windows as part of
a test environment for dbus). That's consistent with the requirement
that we remove distributable-but-non-Free files like RFCs from source
tarballs even if they aren't used in the binaries, which is another
frequently-disagreed-with but consistently-applied policy.

I personally think the project is sometimes too absolutist in its
interpretation of DFSG §2, but I think I'd have trouble establishing
consensus for any less draconian interpretation. Establishing consensus
for "grey areas" is always difficult, because you get into questions
about where to draw the line, and I don't have a good answer to those
questions beyond "I know an (un)acceptable package when I see one",
which is not particularly principled or defensible.

It's entirely possible that an absolutist position is in fact the
pragmatic thing to do, because establishing consensus about the right
line to draw would be more effort than repacking some tarballs :-)

> Looking at
> https://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html
> I can still see that we have more than 1000 source packages in the
> archive that ship those files. So I think you are not correct if you
> claim that we treat them as release-critical bugs at the moment
> otherwise I would expect this Lintian tag to be an error not a pedantic
> issue.

I'm surprised this tag is so low-priority, to be honest: I would have
expected the DFSG-maximalist faction among Debian contributors to have
made it at least a warning. Presumably the assumption is that those
prebuilt Windows binaries all come with source code, otherwise they would
have been rejected at NEW time?

Regards,
    smcv