Greetings Helmut! Thanks for engaging productively on this!
<quote who="Helmut Grohne" date="Sat, Nov 25, 2017 at 08:03:10AM +0100"> > 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. Got it. We agree about that. I'm don't think we agree on what constitutes the source for this package. Until we do, I think a more descriptive title might be better. Something like: "configure file cannot be regenerated automatically." > 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? I agree that a hand-modified binary a binary would not mean that you don't need to provide source for that binary. I think there's likely going to be consensus on that in Debian. I also think this situation is different because I think that a configure file is more like computer-generated, hand-modified, /source/ than like a binary. I think one could also argue that there is an difference between the program binary and a build script which is used to build the package in question. > 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. To say that DFSG#3 is moot (i.e., that you /can not/ make modifications or derived versions) seems to me to be an exaggeration. It is more difficult than it might be if the software and build scripts were created in a different way. But that's not necessary a DFSG issue. Writing your software in a obscure programming language makes it harder to modify as well and that is obviously allowed. Are you willing to say that source code can never contain code that was partially generated by another program that is provided? Even if it is generated by computers and then modified by hand? That's a much stronger position than I think is supportable by any reading of the DFSG than I've ever heard and it would eliminate many hundreds or even thousands of packages from Debian. > > 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). This is distinctly different. The source code in the JS example is obviously not minified the Javascript if we use the GPL's "preferred form for modification" heuristic regardless of the change in question. If upstream wanted to make a change to the Javascript in their program, they would almost never use the minified version. If most's upstream wanted to make a change to their configure file, they would likely modify the pre-built version. Or they would go through rebuilding it again. > 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. I agree! But I think that having packages removed from testing (as has now happened to most) over this interpretation is an overreaction to what I think constitutes an annoyance. I think that the main goal should be focusing on trying to fix these bugs. I think a secondary goal should be discussing this in a systematic way to get some sort of consensus. Until then, my sense is to reduce the severity of this (likely to normal) and to retitle the bug as described above. As I said, I think this is a real bug. I just don't agree that it's a showstopper or a DFSG issue. Regards, Mako -- Benjamin Mako Hill http://mako.cc/ Creativity can be a social contribution, but only in so far as society is free to use the results. --GNU Manifesto
signature.asc
Description: PGP signature
