2014-04-26 07:51 Ben Finney:
"Steve M. Robbins" <st...@sumost.ca> writes:
On April 25, 2014 11:02:29 PM Ben Finney wrote:
> We promise the source for everything any recipient downloads as part
> of Debian. If non-source files are distributed in Debian source
> packages, without a way to confidently guarantee the corresponding
> source is what's already available in Debian, then that is a
> definite impact on the freedom of Debian recipients: it threatens
> the freedom promises in the Social Contract.
That is certainly not a universally held view. Some of us [1] regard
random trash littering the source distribution -- but not used in
generating the actual software (binary distribution) -- as merely a
nuisance that can be tolerated.
If it's in the Debian source package, it is distributed as part of
Debian.
What's your position on 'configure' scripts for which we don't know if they are
generated from the .ac? (Is there a good method to even test this?). Are they
also missing the source?
If the versions of autotools used by upstream generating code from the .ac into
'configure', not shipped in [almost?] any source packages, were not even ever
packaged in Debian (or patched in upstream's distributions or local systems), we
are missing the source (preferred form of modification) of 'configure' script as
well. Svante explained in a previous e-mail of this thread a case with
Makefile/.in/.am.
This has important consequences, and IMO much more serious than the case of
minified JS. If we regenerate 'configure' from the .ac for all packages, part
of the tests and compilation flags at build time will change, most likely
runtime behaviour will change as well. I think that there were even security
problems reported recently related with this.
If you agree that "source-is-missing" also applies in those cases, do you also
think that we should immediately declare all source packages in Debian
containing a 'configure' script as somehow non free (unless we can check
unambigously that they were generated by the .ac), and emit lintian errors
asking all the source packages are repackaged stripping the 'configure' script
and regenerating from the .ac? Or what alternative solutions are acceptable for
you?
(I'm in favour of regenerating 'configure' scripts automatically as expressed in
another recent thread, but because of ports and other practical purposes... and
because they actually are a central part of building every package in which they
are present. But I would also be against requiring to strip source packages of
this file just because we don't know exactly where its source comes from -- that
would be Very Silly and counter-productive).
If it's distributed as part of Debian, it is subject to the promises in
the Debian Social Contract.
Those promises include the promise that anything in Debian has its
source in Debian.
[...]
What part are you saying is “not a universally held view”, and how do
you reconcile that with the Debian Social Contract?
My understanding is that SC and DFSG, similarly to the definition of Free
Software by FSF and other efforts, were devised to promote user freedom when
using and modifying software, etc.
If the consequence of following SC and DFS *Guidelines* (SC#1 refer to it) does
not further these goals, it is an exercise in futility, and thus not worth doing
in my opinion. Interpreting SC or DFSG (or any law or guideline, for that
matter) without thinking of the utility, the costs or the consequences, does not
seem very wise to me.
"source-is-missing" is not important if we (or the users) don't need, or even
use or want, the source or the derived file. And if they want to use/modify it,
they can easily get it, and in fact it is *better* if they get it from JQuery
upstream (or our canonical Debian package) than from the upstream project that
ships it (more recent fixes, etc).
Every person with knowledge about how to modify the minified JQuery, or to ask
some other person to do it for them, will know (the minified file tells them)
where to get the preferred form of modification, change them to their heart's
content, and replace it. In principle most versions will work fine; and people
who want to modify it will generally just grab the latest one from upstream,
from another file their system or a Debian package, or elsewhere. So I think
that not having the unminified file in the same source package doesn't have any
practical negative consequence for users.
I could be mistaken, though. I asked in several emails of the thread for people
to provide realistic examples in which doing the huge *collective* work of
repackaging thousands of source packages improves user freedom in any way, but I
think that nobody provided an example.
So unless/until somebody does that, I consider all this issue a futile effort
(and by wasting time and energy of this, we are actually harming other aspects
of Debian, etc...). I would wish it to stop before more maintainers spend time
on this; but I the meantime I think the lintian error incorrect/irrelevant, and
overridable.
That promise entails a confident guarantee that the source corresponding
to any non-source file – such as an obfuscated Javascript file's
corresponding source form – is in Debian.
I think that it was already pointed out, this has some important practical
problems.
From the persepctive of "source is missing", unless we know that there's an
unambiguous way to check if a minified version corresponds to an unminified one
(checksums can help, but probably not all cases), asking upstream to provide the
unminified version is not a good solution, it's an extra complication which does
not guarantee us that minified matches unminified.
And having minified+unminified would be just another case of embedded 3rd party
libs.
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/20140426142636.ga9...@lugh.itsari.org
