On Fri, Nov 24, 2017 at 06:22:05PM -0800, Benj. Mako Hill wrote: > I'll also say that I'm skeptical about both the severity you've chosen > here (serious), about describing this as a FTBFS issue, and about your > suggestion that this is a DFSG issue.
I deliberately avoided the FTBFS language, because it is not a FTBFS. It's different. It's like shipping a binary that cannot be regenerated and using that during build. The term FTBFS is well defined and does not cover this case. > If there is a serious DFSG issue here, it's not a FTBFS issue but > rather a question of whether or not the source package contains the > full source in the first place. I'm open to being convinced otherwise > but I think it does. I do believe that this is a DFSG issue. > If I generate a configure file with autoconf and then modify it by > hand in order to create a working build script, I don't I've somehow > made it impossible to provide source for that package. I think I'm > still providing the preferred form of modification (as the GPL defines > source). I agree that that situation is brittle and bad and should be > avoided. But I don't think it's a DFSG issue. Would you say the same if you compile a binary, use a hex editor to fix the binary and then ship the binary in your source package? I mean you preferred to edit the binary with a hex editor, so wouldn't it be preferred form for modification? Now consider my case. Most commonly, I want to change AC_RUN_IFELSE into AC_TRY_COMPILE or AC_COMPUTE_INT. That's a very simple change on configure.ac that produces a big diff on the generated configure. Also consider that autoconf projects tend to ship embedded copies of .m4 files. A bug in those .m4 files is often fixed upstream. Fixing it could be a simple matter of updating the embedded copy if one could regenerate configure. In both of these examples, I very much do not prefer working with the generated configure as it feels very much like editing a binary with a hex editor. Thus I argue that configure is not the preferred form for modification. Shipping only configure makes DFGS #3 practically moot. > If this has been discussed elsewhere or if there is Debian policy on > this I don't know about, I'd appreciate being pointed to this and I'm > happy to defer to this. In the meantime, I'd appreciate help fixing > this issue. I'm not likely to have bandwidth for a few more weeks. I guess we should document this issue class centrally. It is similar to the javascript bundling issue (where people suppose that minified or concatenated javascript files could be considered source). A very similar bu is #874261. #882538 could be called related. This issue comes about every time Debian is bootstrapped for a new architecture as configure tends to have bugs (e.g. ppc64el). I'm seeing it now as I bootstrap Debian for something like a new architecture (cross building). So this is the class of bugs to watch out. Helmut
