Re: [Pkg-javascript-devel] JavaScript policy?
2014-03-28 0:28 GMT+01:00 Ben Finney ben+deb...@benfinney.id.au: Emilien Klein emilien+deb...@klein.st writes: Let's take the example of jquery-lazyload [0]. Both these files are provided in the upstream tarball: - jquery.lazyload.js - jquery.lazyload.min.js With the second one being the minified form of the first one. How will you guarantee that ‘jquery.lazyload.js’ is the corresponding source for the file ‘jquery.lazyload.min.js’? How will you guarantee that holds true every time a new version is released upstream? As we can't make sure we're minimizing the file exactly the same way upstream does, would comparing doubly-minified files work (I need to try, but no suitable computer had hand just now): Provided by upstream: - File A: unminified .js - File B: Upstream-provided .min.js Debian minifies file A: File C: Debian-minified file A Debian minifies files B and C with the same options (e.g. drop copyright notice) to get at the same minified content: File D: Debian-minified file C File E: Debian-minified file B Validation check: If File D and File E are equal, then we can assure file B was minified from file A by upstream. I'll try this out for lazyload and report back. Should the check fail, the package does not build (and then we repackage). Recheck by next package to see if repackageing is still necessary. I feel there is more value in shipping the upstream tarball (if we can assure the minified file comes from the supplied source), as repackaging is an extra step that could theoretically go wrong. +Emilien ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JavaScript policy?
Ben Finney ben+deb...@benfinney.id.au writes: There is a method for [ensuring that every Debian release of the source package ships no files without corresponding source]: Don't distribute the minified file from upstream; instead, distribute only the source form of the work, and compile a minified file during the build of the binary package. What other method do you propose for keeping our promise in the Social Contract? Does it meet that promise with as much certainty as the method I propose above? Emilien Klein emilien+deb...@klein.st writes: 2014-03-28 0:28 GMT+01:00 Ben Finney ben+deb...@benfinney.id.au: Emilien Klein emilien+deb...@klein.st writes: Let's take the example of jquery-lazyload [0]. Both these files are provided in the upstream tarball: - jquery.lazyload.js - jquery.lazyload.min.js With the second one being the minified form of the first one. How will you guarantee that ‘jquery.lazyload.js’ is the corresponding source for the file ‘jquery.lazyload.min.js’? How will you guarantee that holds true every time a new version is released upstream? As we can't make sure we're minimizing the file exactly the same way upstream does, would comparing doubly-minified files work (I need to try, but no suitable computer had hand just now): […] Validation check: If File D and File E are equal, then we can assure file B was minified from file A by upstream. I'll try this out for lazyload and report back. Should the check fail, the package does not build (and then we repackage). Recheck by next package to see if repackageing is still necessary. This is significantly more complex and more prone to false positives, than simply dropping the non-source files from the source package, as I propose. I feel there is more value in shipping the upstream tarball (if we can assure the minified file comes from the supplied source), as repackaging is an extra step that could theoretically go wrong. I think you're engaging in wishful thinking. The process you propose has more steps to go wrong, and more points of potential error, than simply dropping the non-source files from the source package. -- \ “If nature has made any one thing less susceptible than all | `\others of exclusive property, it is the action of the thinking | _o__) power called an idea” —Thomas Jefferson | 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
Re: [Pkg-javascript-devel] JavaScript policy?
2014-03-29 9:57 GMT+01:00 Emilien Klein emilien+deb...@klein.st: I feel we are stuck. In the intent to bring this discussion to a close, would you strongly disagree if I ask the question on the -devel mailing list? Let me rephrase that: I will send a draft of the email on our js mailing list, presenting both sides on this question. All will have a say to make this better, and then I'll send it to -devel. I'll likely have some time this afternoon. +Emilien I feel it would be beneficial (regardless of the way in which the discussion goes there) to include developers that might have a broader view of the landscape, maybe a bit less down into the specifics of js packaging as we are. We can then record the final decision on our policy page and close out this time-consuming discussion. Have a great Saturday! +Emilien ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JavaScript policy?
Hi Marcello, Hi Emilien Le 29/03/2014 22:33, Marcelo Jorge Vieira a écrit : On Sat, 2014-03-29 at 10:33 +0100, Emilien Klein wrote: 2014-03-29 9:57 GMT+01:00 Emilien Klein emilien+deb...@klein.st: I feel we are stuck. In the intent to bring this discussion to a close, would you strongly disagree if I ask the question on the -devel mailing list? Let me rephrase that: I will send a draft of the email on our js mailing list, presenting both sides on this question. All will have a say to make this better, and then I'll send it to -devel. Just to remember, two year ago this topic was discussed in the debian-devel list. https://lists.debian.org/debian-devel/2012/08/threads.html#00365 Thank you Marcello for this very interesting thread. By the way it's not addressing exactly the question of *this* thread. It originally talks about sources tarball providing minified files and no sources (and where evently sources could exists elsewhere in debian). As initiator of the thread, I may recall that the question we ask is Should we remove from source tarball minified versions of source files existing in tarball. And of course nobody imagines to use those minified files in binary package. In the current thread, David clearly says we can keep them [1] and Ben [2] suggests that it's better to remove the minified files from orig tarball. And in an other thread [3], Marcello said we have to remove them. [1] http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007214.html [2] http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007242.html [3] http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007176.html - I've detail read the thread from Marcello which is mainly beside the subject we are talking about and without quoting too much, what I've understood is that providing both source and minified version makes a consensus. I may have a wrong undestanding of the discussion so if anybody else could have look and gives return... Beside, the question of the trust we can have on the fact that the minified file is safe, which Emilien propose to verify, is only adressed to people using source package outside debian, and from this POV, we may perhaps make some checks as these are kinds of executable files. But we just feel happy when we have xcf, scg or what else source for jpeg, png, tiff or whatever format and we are still unable to prove that they are compile from sources. Hope that this until - will help to the clearify the question. Cheers, -- François-Régis signature.asc Description: OpenPGP digital signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
