2014-04-25 5:20 GMT+01:00 Gunnar Wolf <gw...@gwolf.org>: > Manuel A. Fernandez Montecelo dijo [Fri, Apr 25, 2014 at 01:27:02AM +0100]: >> To both things above, I don't think that this is different to my example of >> 'configure' script without corresponding .ac/.in; and I don't think that >> anybody >> is thinking about adding lintian errors for that or considering those scripts >> non-free (??). > > Just FWIW, I didn't reply to this point because it's been many years > since I last packaged a project using configure scripts (I just work > with languages I am comfortable with, and C is not one of them). As > others have pointed, shipping configure without compiling it from the > .ac/.in is bad and should be seen as a warning, if not directly as a > true bug.
Precisely, this is the core of a recent/ongoing thread, about using dh-autoreconf or something similar to do this automatically for thousands of packages (because it is very annoying for new ports, if nothing else, and of which I am very much in favour). Nobody in the thread tried to apply the same logic with configure script compared to minified .js. The case of configure script is even worse, in my opinion, because it is actually used to compile the binary (unlike minified .js, which in virtually all cases is only shipped to be used for documentation). And it is at least as difficult to check if a configure script actually came from that source as to check if minified js came from another .js. In that situation, nobody proposed that we should strip ./configure from the source packages just because we don't know if it was generated from the accompanying .in/.ac sources of that script (if present there at all), or because any other consideration. People attempt to deal with that sitation acknowledging the problem and by using automatic tools to regenerate it at build time, before starting the build. Nobody is proposing repackaging orig.tar to remove the "source-is-missing" configure script, and nobody argued that this would improve user freedom or benefit our users in any way. As I said, we dealt with the situation of minified jquery in sdlgfx by depending on libjquery-whatever and using dh_link, so the binary packages use the "canonical" version of Debian (with other obvious benefits apart from freedomness/preferred form of modification, like no duplication); which is somewhat equivalent to the result of using dh-autoreconf for configure scripts. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPQ4b8=a3cts-esvug8wu2jk2x2q9wj3m+v6p3xtz71qfat...@mail.gmail.com
