Quoting Antoine Beaupré (2014-01-30 18:27:04) > On 2014-01-30 12:15:00, Jonas Smedegaard wrote: >> Quoting Antoine Beaupré (2014-01-30 16:34:47) >>> For JS it makes sense because of section 4.13 (convenience copies), >>> but the CSS is native... >> >> Not sure I understand you here. Debian do not allow redistribution >> of upstream-compressed JavaScript, but that does not force you to >> compress at runtime: distributing buildtime-complressed JavaScript is >> fine to distribute in Debian. > > Right. > >> Same is in principle true for CSS (and HMTL etc.) but less strongly >> enforced (because such declarative code is more likely to be still >> readable). > > The difference being that the CSS is not "upstream" so we do not need > to fiddle around with symlinks.
I don't follow. What do you mean not "upstream"? What symlinks? I am talking about DFSG requirements above. Are you perhaps talking (also) about user ability to customize (by storing below /etc)? > We can just shipped the compressed code in the binary package and the > original in the source without breaking policy. Do you mean to say that as a difference?!? That's true for both JavaScript and CSS (just not equally strong enforced). >>> We could *suggest* an uglifier of some sort (and the jury's still >>> out on that I guess) but I strongly feel we should compress at build >>> time. >> >> I don't understand what you are saying here. Are you distinguishing >> between "uglify" and "compress", about JavaScript and CSS, or only >> about buildtime and runtime?!? > > I was specifically saying that we could allow users to modify the CSS > and recompress it, in which case we should Suggest: some kind of "CSS > compressor" so that this can be done easily. > > But in my opinion, this shouldn't be a hard Depends: we should > compress at build time and not force people to install nodejs or ruby > to use the photofloat binary package. > > If they want to edit the CSS and recompress it, then yes, they will > need to install one of those bundles, but we shouldn't enforce that if > we can avoid it. I now understand one thing you don't want (mandatory runtime dependency on helper tools), but still not what you do want. Here is - I think - all sensible options: CSS can be compressed or compacted or simply collated during build, and install that once below /usr, or once below /etc with symlink below /usr, or once below /etc recompressed or recompacted on-demand below /var with symlink below /usr. (difference between "compacting" and "compressing" is that the latter has slightly size gain at the loss of readability) I recommend to compact during build, and install that once below /etc with a symlink below /usr. Simply collating during build loose a few kilobytes at the most, but more importantly ships eventual broken CSS undetected (and hard to discover, because it is passed unexamined to the Browser). Installing below /usr (as done now) is frustrating as it allows no option for customization. On-demand recomputing is IMO overdoing it (local admin can run Sass on the file below /etc if they feel the need for that). - 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
