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.
> I am talking about DFSG requirements above. Are you perhaps talking
> (also) about user ability to customize (by storing below /etc)?
Later yes, but here I was specifically talking about 4.13/DFSG and CSS
files which, unless I am mistaken, are not covered because they are not
convenience copies of code.
>> 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).
I am not saying there's a theorical difference, I am saying that in the
case of photofloat there is because the CSS is not a convenience copy.
>>>> 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.
Right.
> 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)
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
> (difference between "compacting" and "compressing" is that the latter
> has slightly size gain at the loss of readability)
Understood.
> 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?
> 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. :)
> Installing below /usr (as done now) is frustrating as it allows no
> option for customization.
Right, I don't object to changing that.
> 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.
--
You Are What You Is
- Frank Zappa
pgpfFlfS5oIZy.pgp
Description: PGP signature
