On 2014-01-30 15:17:31, Jonas Smedegaard wrote: > Quoting Antoine Beaupré (2014-01-30 19:38:15) >> On 2014-01-30 13:25:33, Jonas Smedegaard wrote: >>> 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? >> >> Sorry I wasn't clear again. The CSS files are in the Photofloat, and >> not convenience copies like some javascript files. The symlinks I am >> refering to are the symlinks to the jquery javascript source files >> which we use to regenerated the compressed javascript with triggers. >> >> What I am saying is we don't need such a convoluted, runtime build >> procedure for CSS as they are part of the photofloat source and not >> convenience copies of code. > > Convenience code copies don't require *runtime* compression.
What? Isn't that why we are talking about triggers for javascript?
Sure, maybe it was respecting policy to compress at build time (the
package is in Debian after all), but it is a potential security problem
anyways.
> ...as I wrote 8 hours ago - at the top of this quote!
>
> DFSG issue is lack of proper source (i.e. preferred form of editing).
> Choice of when to compress (if at all) is completely independent from
> that issue.
It seems to me that section 4.13 goes a little further than DFSG then,
as it specifically refers to maintainability of the code from a security
perspective.
>>> 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.
>>
>> That seems fair enough. I would say:
>>
>> a. compress CSS during build (or compact, i don't care)
>
> Seems we agree on that, then.
One down... 4 to go! :)
>> b. install CSS compressed in /var
>> c. install CSS sources in /etc
>> d. provide a clear way for users to get from c to b, but don't do it
>> automatically.
>> e. symlink in /usr to /etc and /var for consistency and simplicity
>
> Why? Seems exactly what I argue below is overkill and you agree with?
Sorry, why what?
I thought you were arguing that recompiling on the fly at runtime is
overkill. Recompiling on the fly at runtime is not what I am suggesting
here.
>>> I recommend to compact during build, and install that once below /etc
>>> with a symlink below /usr.
>>
>> What about the source files? How do people rebuild if they modify in
>> /etc?
>
> You tell me - I suggest to not do such overkill.
Why on earth would we ship undecipherable configuration files in /etc
if we do not allow people to rebuild them from source?
What I propose above (in d) is that we provide a way (either in
README.Debian or with an update-foo script) to recompile from sources in
/etc. That should be simple enough.
>>> 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).
>>
>> I am not sure I understand that, but okay. :)
>
> Many bugs in compiled languages like C cause build failures, whereas in
> interpreted languages like Python they are most often spotted only at
> runtime.
Correct.
> Running testsuites help catch errors early, but for most interpreted
> languages it is uncommon to include a testsuite (and for Nodejs
> specifically many testsuites rely on DFSG-nonfree jshint).
Right.
> Bugs in interpreted languages therefore often need users to spot them.
> Here, bugs in Browser-executed code is especially tricky, because the
> users running into thpse bugs are rarely the geek packaging the code,
> nor a technically savvy Linux user, but someone else running older or
> browsers (especially closed-source ones).
Understood.
> So non-host-executed interpreted languages are arguably the most
> important to apply any form of testsuite for. Running CSS through Sass
> is a simple way of "regression testing" CSS code.
Right, that's what I understood.
I believe it goes beyond our duty as package maintainers to extend
Photofloat to include a CSS test suite. If we could convince upstream of
that, I'm okay with the idea, otherwise I don't think it's necessary.
>>> On-demand recomputing is IMO overdoing it (local admin can run Sass
>>> on the file below /etc if they feel the need for that).
>>
>> Agreed.
>
> Really?
I am not sure I understand what you disagree with here, or what you
think I disagree with.
A.
--
Le Québec ne rêve plus de devenir une société modèle: voilà son
problème d'environnement.
- Pierre Dansereau (1911 - 2011)
pgpAC9eTReHeZ.pgp
Description: PGP signature
