2014-04-25 23:32 Wookey:
+++ 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.
From some hundreds of orig.tar that I have around, the following
examples are generated by autoconf but .ac/.in seems missing. Few in my
survey, but some of them are important.
acl-2.2.52/configure
attr-2.4.47/configure
ccache-3.1.9/configure
(I stopped looking)
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.
I don't know if people agree, but if we accept the premise that the
source and preferred form of modification of 'configure' is
'configure.ac' (and, I would add, the code from autoconf expanding the
functions/macros in .ac is also source of 'configure'), then I don't
agree that the source code of 'configure' is never missing. And other
people argue that not being the preferred form of modification, violates
the DFSG.
If we need to modify the '.ac' to support a new feature, the regenerated
'configure' is potentially very different (and fail to compile, be
buggy, whatever). Once we need to modify the .ac and regenerate, parts
of the "source" of the old 'configure' is more or less effectively
"missing" and lost for any new builds. Generally that's fine and we
don't care, but still, I would argue that conceptually the same is true
of well-known minified JS libs: you take the new unminified, substitute
it, and are done with it -- that the exact source code changes is not
important, as long as it works. And we know that the canonical versions
usually work better than old copies, so good riddance.
If either 'configure' or minified JS were modified by hand (e.g., adding
extra non-minified functions to the minified .js, to provide unrelated
functionality to the original library), or for whatever reason does not
work with newer autoconf, and so regeneration from configure.ac or
unminified JS breaks the build, we have no option but use the original
'configure' and minified JS (not their preferred form of modification).
At that point they are their own preferred form of modification -- until
somebody fixes the project to be compatible with newer versions of the
libs.
So I think that the uses and problems that we have to deal with minified
JS have many parallels with 'configure', at least in the case of
well-known JS libraries.
As you say above, and it is one of the objections of people about
minified JS, in the same way that there is no easy way to say if
'configure' comes from '.ac', there is also no general/sure way to say
about minified JS and unminified source. If that's an argument for
regenerating from .ac (I agree, again) and so we are ignoring the
'configure', I think that it's an argument for ignoring the minified JS
from upstream and linking to the canonical libjs-* (except in cases
where fails).
Crucially, and that's what I am arguing for, I think that nobody thinks
of asking upstream to remove their 'configure' file on the basis that it
might not correspond to the '.ac' (or remove it when there's no .ac but
clearly generated from one, as in my examples above) because in Debian
we think that source-is-missing and thus is non-free for us, specially
***if we don't even use it*** to build the package.
No user will be benefited by that action, neither Debian's or other
users, in fact many will be annoyed for not having the 'configure'
available.
And in the case of minified JS, at least I would feel like an idiot
asking upstream to add new files (unminified JS) that we do not even
intend to use, are free software, and everybody interested knows where
to find them (no benefit for anybody in removing it).
Cheers.
--
Manuel
--
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/20140426181333.ga3...@lugh.itsari.org
