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
