Re: [Pkg-javascript-devel] JavaScript policy?
2014-03-28 0:28 GMT+01:00 Ben Finney : > Emilien Klein 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 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 writes: > 2014-03-28 0:28 GMT+01:00 Ben Finney : > > Emilien Klein 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:17 GMT+01:00 Ben Finney : > 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'm not saying it's even working. I am suggesting a potential solution to getting the response to "is the upstream-provided minified file coming from the same source?". I don't agree that it would be more complex: 2 calls to uglifyjs, and one to diff. Compare that to the 18 lines (and I'm not including the other 10 `rm` lines in there) that are needed for repackaging (example from flotjs [0]), including calls to awk and sed ;) [0] http://anonscm.debian.org/gitweb/?p=pkg-javascript/flot.git;a=blob;f=debian/rules;h=83670cf0ec4aaec4817d6f2eb68d0756d85ac553;hb=HEAD >> 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. Well, my original suggestion is indeed much more simple than the verification of upstream validity and the current policy to repackage: leave the minified files in, as released by upstream under a license that allows explicitly allows its redistribution. As I've tried to explain before, I don't see what in DFSG §2 prevents the inclusion of the minified file: From https://www.debian.org/social_contract.en.html Source Code The program must include source code, and must allow distribution in source code as well as compiled form. I argue that a tarball that contains the source for the program, along with a minified file next to it is fulfilling "The program must include source code". As explained before as well, the minified file is provided by upstream as a convenience to it's users, it's implicitly coming from the source of the program. DFSG §2 does not say something along the lines "The program must *only* include the source code, excluding any files included by upstream for the convenience of the user" 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? 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?
2014-03-29 9:57 GMT+01:00 Emilien Klein : > 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?
Quoting Emilien Klein (2014-03-29 09:57:20) > 2014-03-29 9:17 GMT+01:00 Ben Finney : >>> 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. > > Well, my original suggestion is indeed much more simple than the > verification of upstream validity and the current policy to repackage: > leave the minified files in, as released by upstream under a license > that allows explicitly allows its redistribution. ...and blindly assume that source and minified file corresponds. > As I've tried to explain before, I don't see what in DFSG §2 prevents > the inclusion of the minified file: Correct - it does not prevent that. We never said it prevents that. What it does is require source for any and all files we distribute. > I argue that a tarball that contains the source for the program, along > with a minified file next to it is fulfilling "The program must > include source code". That is quite possible, but not certain. > DFSG §2 does not say something along the lines "The program must > *only* include the source code, excluding any files included by > upstream for the convenience of the user" I fully agree. I do not agree in blindly trusting upstream, however. > 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? > 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. I recommend you to try address the questions raised by Ben. Feel free to escalate to d-devel, but don't expect to have better luck there. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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
Re: [Pkg-javascript-devel] JavaScript policy?
Hello, On Sat, 2014-03-29 at 10:33 +0100, Emilien Klein wrote: > 2014-03-29 9:57 GMT+01:00 Emilien Klein : > > 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 Cheers, -- Marcelo Jorge Vieira xmpp:me...@jabber-br.org http://metaldot.alucinados.com signature.asc Description: This is a digitally signed message part ___ 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 : >>> 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