+++ Manuel A. Fernandez Montecelo [2014-04-25 09:42 +0100]: > > ... a recent/ongoing thread, about using dh-autoreconf or something > similar ...
> 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. I see the point you are getting at, but don't agree that the situations are equivalent. First I have never seen a package (and I've looked at a lot) where the source (configure.in/ac) is missing. So the source is never missing, and re-generating it is thus straightforward. Also the configure script, whilst not entirely 'preferred' is perfectly modifiable, comprehensible, with comments and variables and so on, so again it's at least much further up the scale of 'preferred/modifiable' than minified js. It's a much harder call to say that it doesn't count as source for DFSG purposes. I'm not sure that generation itself makes something 'not source'. It is possible that the shipped configure is not what you'd get from regenerating - i.e. it doesn't match the 'source' provided, and we don't check for that. But this is just another argument for re-autoconfing, which we have agreed is a good thing for other reasons too, and as we have all the parts we need, there is no issue of source availability. > 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. This seems fair enough to me. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20140425223258.gh29...@stoneboat.aleph1.co.uk
