Emilien Klein <emilien+deb...@klein.st> writes: > Hi Ben, > > 2014-03-26 22:30 GMT+01:00 Ben Finney <ben+deb...@benfinney.id.au>: > > Emilien Klein <emilien+deb...@klein.st> writes: > > > >> The current policy is made using the assumption that minified == compiled. > >> For my information: Has this ever clearly and definitively been > >> established? > > > > I'm not understanding your question. What assumption are you describing? > > I am mentioning the fact that our policy mandates to repackage > upstream tarballs if they contain minified files, based on the > assumption that a minified file is a compiled resource (I almost wrote > "compiled binary", which is what I think of when thinking of > compilation, but that is obviously not true as a minified JavaScript > file is not a binary file)
What makes you think the policy is “based on the assumption that a minified file is a compiled resource”? My understanding is that the policy is based on the fact that a minified file is a non-source form of the work, and the source package should contain only the source form of the work. > > Equating “minified” with “compiled” is not, AFAICT, an assumption; > > it is describing different aspects of the same process. > > That is exactly what I want to see confirmed. Is everybody (not just > our smallish team of JS packagers) agreeing on the fact that a > minified file is a compiled file? I don't see how disagreeing on that terminology would change the policy, since AFAICT the policy is not based on the definition of “compiled”. > > Would you agree that we should not be shipping non-source forms of > > works that we can't guarantee have not been fiddled with? > > Regarding the sentence that you cite below (regarding DFSG §2), I > think there is no issue in redistributing an upstream tarball that > contains the minified file from it's own source code. If the tarball > only contained the minified file, I would obviously object. But if the > tarball contains the source .js and the minified .min.js, I'm not sure > we are in breach of DFSG §2 as the source is provided. The issue raised by that is, of course, how can we know that the non-source form of the work corresponds to the source form we are distributing? One way to be sure is to discard the non-source form we receive, and built it from the source. Then we don't need to assume anything about the non-source form we received; we can know that the result of the build corresponds to the source form of the work. > Since we re-minify as part of our build process (should also be > specified in our policy), the binary packages contain the source and > the by-us-ensured-valid minified file. The .orig tarball then remains > the same as provided by upstream. If we're distributing a non-source file in the source package, we run the risk of that file not corresponding to any source that we distribute. How do you propose we remove that risk? The risk is reduced to zero by discarding the non-source file we receive, and building it from the source. > I believe most upstreams are in good faith, providing the minified > files as a service to their users that can just extract that file and > use it on their servers. Regardless of good faith, people can make mistakes or omissions. Why bother with a file that could quite easily violate our social contract, when we can just discard the non-source file from the source package and thereby avoid that risk? > Have we ever seen a case where an upstream shipped an evil minified > file in their release tarball? Why assume malice, when a simple mistake has the same result? This is, after all, a mistake easily made: upstreams routinely include the non-source form of a JavaScript work as a bundled third-party library, and have little motivation to bother checking that the source form corresponds with what they're shipping to us. -- \ “[Entrenched media corporations will] maintain the status quo, | `\ or die trying. Either is better than actually WORKING for a | _o__) living.” —ringsnake.livejournal.com, 2007-11-12 | Ben Finney _______________________________________________ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
