On Fri, 25 Apr 2014 10:47:20 +0100 "Manuel A. Fernandez Montecelo" <manuel.montez...@gmail.com> wrote:
> 2014-04-25 8:49 GMT+01:00 Matthias Urlichs <matth...@urlichs.de>: > > Hi, > > > > Manuel A. Fernandez Montecelo: > >> a) the minified .js is still source code, by definition. > > > > Sorry, but _my_ definition of "source code" is "whatever you > > customarily edit when you want to change something". > > > > _Nobody_ in their right mind edits minified Javascript. > > (I know that we're more on less in the same page, but I will reply > to your message about what I meant of the importance of the sourceless > file being valid source code and setting this apart from other cases). > > > I expect that if users want to modify that JS, they are smart enough > to get the unminified source (which the minified version publicises > well in some/most cases), edit, minify again (if they feel like it) > and replace the original modified file [1]. No. The requirement is that the source is part of the source package. If you provide the javascript at all, it's the non-minified version or rely on the packaged version entirely and have no JS in the orig.tar.gz. Minified JS is not source code, either replace it with source code in the orig.tar.gz or don't include it in the orig.tar.gz in the first place. > With the same reasoning, nobody in their right minds edit 30-k lines > configure scripts (except maybe for quick fixes like disabling some > test, or adding a path to search). Wrong. configure is properly indented, it uses full names for variables and it uses lots of whitespace. Despite it's length, it is perfectly acceptable to edit configure and then port the fix to configure.ac. > In these two cases, "source-is-missing" (lintian error) has very > different consequences than "source-is-missing" for a precompiled > binary without source, a blob of firmware, or a .swf file. Minified > .js is just normal source code in the eyes of the interpreter, ./configure is perfectly acceptable to the bash interpreter. This isn't about interpreters, it's about humans. > and > thus can be replaced with the unminified version if users want to > modify it; something that you cannot do with "source-is-missing" in > other cases. The unminified version needs to be in the source. > And if the unminified souce code is there (I am not 100% conviced if > with the minifed version, but well, let's drop that case), or can be > obtained easily (as it is the case with jquery), we're not violating > the license even if the version is not in Debian (will fail DFSG if > the minified is not accepted as "source" code, but well, since you can > substitute it for other version, l think that this is a rather > whimsical interpretation of the *guidelines*). The GPL (I don't think > that others are stronger on this point): It's not just about the licence, it's about development and debugging. > Thus, the file itself being source code, interpreted by the same > interpreter as the unminified source code and being possible to > substitute it for other versions easily modificable, makes the case > completely different than other cases of "source-is-missing". So I > believe that the lintian error considering these dissimilar cases > together is wrong, and overriding is a reasonable solution (specially > once that it's dealt with for shipped binaries). No. This is about editing in-place inside the directory created by apt-get source. > Unless/until somebody provides compelling reasons (or CTTE or GR), I > will heed the advice of ignoring this lintian error. Fix the package properly. > I was arguing against repackaging source packages. Then work with upstream to package the required files. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
