Samuel Thibault writes:
> I however agree that it seems poor practice to duplicate these build
> modules in every packages. But if the required versions are different,
> there is no real other way.
There is another solution: put several different versions of the same
On Fri, 04 Sep 2015 17:54:30 +0200
Vincent Bernat wrote:
> ❦ 4 septembre 2015 09:32 +0100, Neil Williams
> :
>
> [Applying patch to pre-minification source]
> >> Getting the same min.js is not a goal (we don't try to get the same
> >> binaries than
❦ 4 septembre 2015 09:32 +0100, Neil Williams :
[Applying patch to pre-minification source]
>> This will become more difficult with jQuery 3.x (due to ES6 to ES5
>> transformation). But manual adaptation should stay straightfoward
>> ("transpilation" only does local
On Thu, 03 Sep 2015 22:51:50 +0200
Vincent Bernat wrote:
> ❦ 3 septembre 2015 13:19 -0700, Nikolaus Rath :
>
> > 2. Many javascript packages cannot be build from source with the
> > tools in main.
>
> This is the one I don't agree. For me,
❦ 4 septembre 2015 08:29 +0100, Neil Williams :
>> > 2. Many javascript packages cannot be build from source with the
>> > tools in main.
>>
>> This is the one I don't agree. For me, pre-minification source is
>> source code. If you show the pre-minification version of
On Fri, 04 Sep 2015 10:07:13 +0200
Vincent Bernat wrote:
> ❦ 4 septembre 2015 08:29 +0100, Neil Williams
> :
>
> > For those upstreams who have to embed JS not available in Debian,
> > then the upstream code often cannot be processed in Debian, neither
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Sep 03, 2015 at 08:47:11AM +0200, Vincent Bernat wrote:
> Without minification, we'll just ship packages that people won't
> use. Why would I run a crippled installation of Wordpress that will
> drive of part of my users to another competitor?
* Bas Wijnen [150902 17:36]:
> > On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich wrote:
> > > No, "A preferred form" is what upstream uses. The DFSG does not use
> > > the term "THE preferred form", and I believe that was wise.
>
> The DFSG doesn't define
❦ 3 septembre 2015 17:22 GMT, Bas Wijnen :
> Because you know you have the right and the ability to be a part of the free
> software community that created the software. That is why you are running
> Debian and don't have contrib or non-free in your sources.list.
>
> From
* Neil Williams [150902 14:15]:
> On Wed, 2 Sep 2015 13:14:31 -0400 Marvin Renich wrote:
> > It is presumed that upstream already has what it considers "source";
> > in the case of this thread, that is minified JS.
>
> Actually, not. Source, for upstream of
Lars Wirzenius dijo [Wed, Sep 02, 2015 at 09:32:12AM +0300]:
> However, I want to raise the point that upstreams do not always make
> sensible decisions, and if they don't, it's good to raise that with
> them. For example, there was recently an ITP bug for
> node-number-is-nan. Upstream source
* Neil Williams [150902 14:33]:
> Minified isn't source for modification... [large snip]
I don't believe I have disagreed with anything you said in the snipped
text. I certainly did not mean to. I said that minified JS can only go
in main if both the source and the tools
Paul Wise writes:
> On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote:
>> If *no one* has access to anything better than a binary file, then
>> possession of that binary file puts you on an equal footing with
>> everyone else in the world, which I think is all that we can
Vincent Bernat dijo [Wed, Sep 02, 2015 at 09:47:23AM +0200]:
> If you talk about uglifyjs or the like, it is already packaged and
> doesn't solve all the problems we have (see my message to Odyx,
> ).
>
> If you talk about Grunt, Grunt comes with a lot of plugins (and
On Sep 03 2015, Vincent Bernat wrote:
> ❦ 3 septembre 2015 17:22 GMT, Bas Wijnen :
>
>> Because you know you have the right and the ability to be a part of the free
>> software community that created the software. That is why you are running
>> Debian and
❦ 3 septembre 2015 13:19 -0700, Nikolaus Rath :
>>> Because you know you have the right and the ability to be a part of the free
>>> software community that created the software. That is why you are running
>>> Debian and don't have contrib or non-free in your sources.list.
On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote:
> I think reading "preferred form of modification" from the perspective of
> upstream is a useful standard because it handles some edge cases like
> that, and because it feels ethically consistent with free software
> principles. The goal is
❦ 3 septembre 2015 12:23 +1000, Dmitry Smirnov :
>> Amazon did a study that showed every ~100ms of page load
>> delay lost them 1% in sales.
>
> It could be that small percentage of Amazon users are impulsive trigger-happy
> buyers. :)
> However that conclusion is probably
On Thursday 03 September 2015 08:47:11 Vincent Bernat wrote:
> Please, publish your own study.
I do not need to publish any studies to be sceptical.
> This number is well known and supported
> by an entity which is likely to have a population large enough to be
> significant.
You've mentioned
❦ 3 septembre 2015 21:03 +1000, Dmitry Smirnov :
>> Without minification, we'll just ship packages that people won't
>> use. Why would I run a crippled installation of Wordpress that will
>> drive of part of my users to another competitor?
>
> Sorry but that feels like
❦ 2 septembre 2015 09:32 +0300, Lars Wirzenius :
> However, I want to raise the point that upstreams do not always make
> sensible decisions, and if they don't, it's good to raise that with
> them. For example, there was recently an ITP bug for
> node-number-is-nan. Upstream
Vincent Bernat, le Wed 02 Sep 2015 09:47:23 +0200, a écrit :
> If you talk about Grunt,
That's what I'm talking about.
> Grunt comes with a lot of plugins (and does almost nothing without
> those) and each upstream will require different plugins with different
> versions (Grunt plugin versions
❦ 2 septembre 2015 09:54 +0200, Samuel Thibault :
>> If you talk about Grunt,
>
> That's what I'm talking about.
>
>> Grunt comes with a lot of plugins (and does almost nothing without
>> those) and each upstream will require different plugins with different
>> versions
❦ 2 septembre 2015 09:28 +0200, Samuel Thibault :
>> Healthy language communities have their own metadata systems and
>> standardized build systems that allow Debian packaging to be nearly
>> automated, *provided* that we use the same unit of distribution as
>> upstream.
Russ Allbery, le Tue 01 Sep 2015 18:05:09 -0700, a écrit :
> Healthy language communities have their own metadata systems and
> standardized build systems that allow Debian packaging to be nearly
> automated, *provided* that we use the same unit of distribution as
> upstream.
I understand that
Vincent Bernat, le Wed 02 Sep 2015 10:10:55 +0200, a écrit :
> ❦ 2 septembre 2015 09:54 +0200, Samuel Thibault :
>
> >> If you talk about Grunt,
> >
> > That's what I'm talking about.
> >
> >> Grunt comes with a lot of plugins (and does almost nothing without
> >> those)
❦ 2 septembre 2015 10:18 +0200, Samuel Thibault :
>> Or maybe you propose to just ship the whole "node_modules" directory
>> (which has all the dependencies) with jQuery sources?
>
> That'd be a lot better than nothing.
OK. Also, node_modules for jQuery is 76M (for 3.x,
On Tue, Sep 01, 2015 at 06:05:09PM -0700, Russ Allbery wrote:
> Healthy language communities have their own metadata systems and
> standardized build systems that allow Debian packaging to be nearly
> automated, *provided* that we use the same unit of distribution as
> upstream. If we want to
* Ben Hutchings [150902 10:12]:
> My preferred form is a git repository of code written in C, Python, or
> some other language I know. That doesn't mean that a tarball of
> Haskell code is non-free!
I can't tell whether you are agreeing or disagreeing with me!
> The
* Neil Williams [150902 10:22]:
> Upstream is another recipient of code distributed under copyleft.
> Having changes in a format which upstream can use is absolutely a
> sensible and sane criterion for what is regarded as the form of the
> code for modification. To do
On Wed, 2 Sep 2015 13:33:57 -0400
Marvin Renich wrote:
> * Ben Hutchings [150902 10:12]:
> > My preferred form is a git repository of code written in C, Python,
> > or some other language I know. That doesn't mean that a tarball of
> > Haskell code is
On Tuesday 01 September 2015 17:46:30 Josh Triplett wrote:
> Nikolaus Rath wrote:
> > I don't think 28 kB vs 73 kB is a difference that people will notice
> > over the network in *most* situations. Even at just 100 kB/s that's
> > 0.28 vs 0.73 seconds, and only when the page is first loaded.
>
>
On Wed, 2 Sep 2015 13:14:31 -0400
Marvin Renich wrote:
> * Neil Williams [150902 10:22]:
> > Upstream is another recipient of code distributed under copyleft.
> > Having changes in a format which upstream can use is absolutely a
> > sensible and sane
The below is very much a tangent from the minified Javascript case, and
not applicable to that case.
Bas Wijnen writes:
> Here's a rule to limit the selection a bit: a file is certainly not
> source if it was originally generated from a different file, and has not
> been
At Tue, 1 Sep 2015 18:56:45 +0200,
Raphael Hertzog wrote:
> For me, the javascripts bits in wordpress/publican are not part of the
> product, they are external libraries whose preferred form of use is
> by embedding a copy of the library... that sucks but it's the way it is.
>
> I do not see
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Sep 02, 2015 at 07:33:10PM +0100, Neil Williams wrote:
> On Wed, 2 Sep 2015 13:33:57 -0400
> Marvin Renich wrote:
>
> > * Ben Hutchings [150902 10:12]:
> > > My preferred form is a git repository of
Vincent Bernat debian.org> writes:
> 2. Upstream may generate the final pre-minification file with complex
> tools, like an AMD loader or an ES6/ES5 transpiler, along with the
> use of non-packaged build tools like Grunt.
> problem. For the second one, a solution would be to consider
Vincent Bernat, le Wed 02 Sep 2015 11:20:32 +0200, a écrit :
> ❦ 2 septembre 2015 10:18 +0200, Samuel Thibault :
> >> Or maybe you propose to just ship the whole "node_modules" directory
> >> (which has all the dependencies) with jQuery sources?
> >
> > That'd be a lot
* Thorsten Glaser [150902 07:50]:
> There is (I just had an epiphany) another possible criterium to apply
> for to determine what the preferred form of modification is:
^ for
[Okay, so I'm being pedantic, but this is a common
On Wed, 2015-09-02 at 08:59 -0400, Marvin Renich wrote:
> * Thorsten Glaser [150902 07:50]:
> > There is (I just had an epiphany) another possible criterium to apply
> > for to determine what the preferred form of modification is:
>^
On Wed, 2 Sep 2015 08:59:11 -0400
Marvin Renich wrote:
> * Thorsten Glaser [150902 07:50]:
> > There is (I just had an epiphany) another possible criterium to
> > apply for to determine what the preferred form of modification is:
>
❦ 1 septembre 2015 21:10 +0200, Didier 'OdyX' Raboud :
> I think we should take a strong move there and exercise (as well as
> justify to the outer world) our free software right to recompile the
> software that we ship to our users: this could mean to only merge & gzip
>
On Sep 01, Nikolaus Rath wrote:
> I don't think 28 kB vs 73 kB is a difference that people will notice
> over the network in *most* situations. Even at just 100 kB/s that's
> 0.28 vs 0.73 seconds, and only when the page is first loaded.
Yes, this is a non trivial difference
Vincent Bernat dijo [Fri, Aug 28, 2015 at 10:48:28AM +0200]:
> >> What will happen is that maintainers will fallback to the second less
> >> horrible solution and cripple the package (by using an older version of
> >> the JS lib for example) to allow it to stay in main.
> >
> > Why would they want
Le mardi, 1 septembre 2015, 17.50:26 Vincent Bernat a écrit :
> ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
> >>> Couldn't we just use the non-minified versions in most situations?
> >>> A
> >>
> >> Not for anything which has actual users over the network.
> >
> > Why?
* Raphael Hertzog [150901 12:57]:
> Because we have alternative "compilers" (aka minifier) available to
> recreate another minified file thas should work just as well.
No. Debian does not allow you to ship a compiled C program that was
compiled elsewhere; the maintainer or a
On Tue, Sep 01, 2015 at 04:42:15PM +0200, Helmut Grohne wrote:
> On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
> > Couldn't we just use the non-minified versions in most situations? A
> > heavily loaded wordpress site might not be good example but e.g. doxygen
> > documentation
Vincent Bernat dijo [Fri, Aug 28, 2015 at 11:54:43AM +0200]:
> > I still find it hard to believe that *so* much code is required to
> > minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> > would appear to be that nobody actually *cares* about the mess, they
> > just use it.
❦ 1 septembre 2015 13:45 -0500, Gunnar Wolf :
>> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not
>> require only minification. They require transpiling (convert from ES6 to
>> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency
>>
On Tue, 01 Sep 2015, Vincent Bernat wrote:
> 1. Upstream may not ship this source but only the minified version
> because the JS code is just a dependency and some upstream are used
> to just ship the minified source. We can recover the original code
> from another source but there is a risk
Hi,
On Mon, Aug 31, 2015 at 09:50:05AM +0200, Raphael Hertzog wrote:
> On Mon, 31 Aug 2015, Simon Josefsson wrote:
> > How would someone rebuild the minified javascript files from the
> > missing-sources files?
>
> They would not?
>
> The modified non-minified files are perfectly usable even if
Josh Triplett writes:
> That said, we absolutely do need to fix this in Debian: it's not OK to
> build packages in main using tools not shipped in Debian, or to ship
> precompiled files. As a start, it would help if when JavaScript folks
> try to package the packages
On Sep 01 2015, Josh Triplett wrote:
> Nikolaus Rath wrote:
>> I don't think 28 kB vs 73 kB is a difference that people will notice
>> over the network in *most* situations. Even at just 100 kB/s that's
>> 0.28 vs 0.73 seconds, and only when the page is first loaded.
>
>
Nikolaus Rath wrote:
> I don't think 28 kB vs 73 kB is a difference that people will notice
> over the network in *most* situations. Even at just 100 kB/s that's
> 0.28 vs 0.73 seconds, and only when the page is first loaded.
That's absolutely a critical difference, even on a faster connection.
On Sep 01, Guido Günther wrote:
> Couldn't we just use the non-minified versions in most situations? A
Not for anything which has actual users over the network.
> heavily loaded wordpress site might not be good example but e.g. doxygen
> documentation probably doesn't suffer
❦ 31 août 2015 11:21 -0400, Marvin Renich :
>> > However, this is a readable source code that will accomodate any
>> > modification that a end user will deem necessary.
>
> I intentionally did not look at the file referred to above, and have no
> idea whether I would consider
On Sep 01 2015, Vincent Bernat wrote:
> ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
>
Couldn't we just use the non-minified versions in most situations? A
>>>
>>> Not for anything which has actual users over the network.
>>
>> Why? (Don't forget
Hi,
On Mon, 31 Aug 2015, Bas Wijnen wrote:
> > I certainly do not want to move wordpress or publican to contrib because
> > some of the javascript libraries that it uses can't be rebuilt from main.
>
> In that case, my question applies to you as well: why do you care for it to be
> in main, if
On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
> Couldn't we just use the non-minified versions in most situations? A
> heavily loaded wordpress site might not be good example but e.g. doxygen
> documentation probably doesn't suffer much from non minified JS.
I fail to see what
On Sep 01 2015, m...@linux.it (Marco d'Itri) wrote:
> On Sep 01, Guido Günther wrote:
>
>> Couldn't we just use the non-minified versions in most situations? A
>
> Not for anything which has actual users over the network.
Why? (Don't forget about gzip encoding).
Best,
❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
>>> Couldn't we just use the non-minified versions in most situations? A
>>
>> Not for anything which has actual users over the network.
>
> Why? (Don't forget about gzip encoding).
See:
> On Mon, Aug 31, 2015 at 11:21:55AM -0400, Marvin Renich wrote:
> > * Bas Wijnen [150830 07:53]:
> > > On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> > > > Is that the preferred form of modification? It depends, but from the
> > > > jQuery author point of
On Sep 01 2015, Helmut Grohne wrote:
> On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
>> Couldn't we just use the non-minified versions in most situations? A
>> heavily loaded wordpress site might not be good example but e.g. doxygen
>> documentation probably
On Sun, 30 Aug 2015, Bas Wijnen wrote:
> Why do you care that software is in main, if you evidently do not care about
> any of the rules we have for it?
I don't think that implying that Vincent doesn't not care about Free
Software is very constructive.
Can we please stop this now?
If all the
Raphael Hertzog writes:
> In both cases, I worked around the problem by shipping the upstream
> sources in debian/missing-sources/ but I did not support doing changes
> there and did not rebuild the embedded libraries.
>
> In some cases, I do replace the embedded library with
On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote:
> Not regenerating configure doesn't pose any significant risk that
> we're shipping a configure script that we can't regenerate (or, at
> least, regenerate an equivalent or better one). I've not heard of
> people (for example) using
On Thu, Aug 27, 2015 at 04:14:53PM -0700, Russ Allbery wrote:
> Last time I checked, Doxygen includes minified Javascript in all of its
> generated output. Would we have to move every piece of Doxygen-generated
> documentation into a separate package so that we could put it in contrib,
> or strip
First, let me make it clear that I am firmly in the camp that believes
minified JS cannot be distributed in main unless the tools to recreate
it are also in main. It bothers me that there appears to be a
not-insignificant number of people with upload rights who do not believe
this.
This message
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Aug 31, 2015 at 08:49:53AM +0200, Raphael Hertzog wrote:
> On Sun, 30 Aug 2015, Bas Wijnen wrote:
> > Why do you care that software is in main, if you evidently do not care about
> > any of the rules we have for it?
>
> I don't think that
On Mon, 31 Aug 2015 at 16:50 Raphael Hertzog wrote:
> In both cases, I worked around the problem by shipping the upstream
> sources in debian/missing-sources/ but I did not support doing changes
> there and did not rebuild the embedded libraries.
>
I haven't been paying lots
Raphael Hertzog writes:
> On Mon, 31 Aug 2015, Simon Josefsson wrote:
>> How would someone rebuild the minified javascript files from the
>> missing-sources files?
>
> They would not?
>
> The modified non-minified files are perfectly usable even if they are a
> bit larger
On Mon, 31 Aug 2015, Simon Josefsson wrote:
> How would someone rebuild the minified javascript files from the
> missing-sources files?
They would not?
The modified non-minified files are perfectly usable even if they are a
bit larger than the minified ones.
> The included JavaScript file is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
The build script determines the outcome of what will effectively run on
our users' machine. I fail to see how this is not an important
issue.
You are correct, this is important.
But
❦ 29 août 2015 19:12 -0700, Steve Langasek vor...@debian.org :
Yet you try to compare this with autoconf. Even if we tolerated configure
scripts today in the archive that we can't rebuild using the software in
Debian (which by and large we do *not* tolerate - because we've learned our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Aug 30, 2015 at 02:12:43PM +0200, Vincent Bernat wrote:
This is becoming quite a stretch. At this rate, we will fail to match
SC#2 because we ship previous versions of software and upstream is
unlikely to accept a patch against a
On Sun, Aug 30, 2015 at 10:14 AM, Vincent Bernat wrote:
The build script determines the outcome of what will effectively run on
our users' machine. I fail to see how this is not an important
issue. But until the effort to get ppc64el, not regenerating the
configure script was just a fine
On 08/28/2015 01:14 AM, Russ Allbery wrote:
Bas Wijnen wij...@debian.org writes:
Last time I checked, Doxygen includes minified Javascript in all of its
generated output. Would we have to move every piece of Doxygen-generated
documentation into a separate package so that we could put it in
❦ 30 août 2015 11:52 GMT, Bas Wijnen wij...@debian.org :
However, this is a readable source code that will accomodate any
modification that a end user will deem necessary.
That is not the only reason that we want the user to have source.
They are not some detached customer. When we make
Bastien ROUCARIÈS, le Sun 30 Aug 2015 23:15:39 +0200, a écrit :
What could be done in order to improve the whole system performance in order
to package really small package ?
Is it not possible to group them like X.org does?
Samuel
Steve Langasek vor...@debian.org writes:
[…] Nevertheless, for packages that *are* in Debian, we should expect
that the source package contains the *full* corresponding source code
for any minified javascript files. If we can't rebuild it then we
don't actually have the source, and that's a
]] Vincent Bernat
1. package the whole Grunt ecosystem (and maintain it),
2. cripple their package by substituting some components by a non-working
version in Debian or,
3. ship a pre-compiled/minified version of the library with sources.
I know this sucks, but if I have to pick my
On Fri, Aug 28, 2015 at 07:42:42AM +0200, Vincent Bernat wrote:
The main effect of this religious and overzealous application of our
guidelines is that people just stay away of JS stuff in Debian and
packaging any web-related app is becoming more complex as anyone needs
to deal with JS
Vincent Bernat ber...@debian.org writes:
28 août 2015 01:46 GMT, Bas Wijnen wij...@debian.org :
Or alternatively, by packaging the minifier that is being used with the
package
that needs it. Yes, that's a horrible idea with lots of code duplication,
but
if I understand the problem,
❦ 28 août 2015 10:29 +0200, Samuel Thibault sthiba...@debian.org :
What will happen is that maintainers will fallback to the second less
horrible solution and cripple the package (by using an older version of
the JS lib for example) to allow it to stay in main.
Why would they want to stay
On Fri, 28 Aug 2015 10:45:16 +0200
Samuel Thibault sthiba...@debian.org wrote:
Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
Maybe it can be trimmed a bit more, but that's still 239 unique
dependencies.
Note that you don't have to make that 239 debian packages, you could
On Monday 24 August 2015 13:54:21 Simon Josefsson wrote:
I believe the blog post below has relevance to Debian's stance on
including minified JavaScript in packages:
https://zyan.scripts.mit.edu/blog/backdooring-js/
Thank you for a nice argument against minification.
During packaging I
Neil Williams, le Fri 28 Aug 2015 10:32:52 +0100, a écrit :
On Fri, 28 Aug 2015 10:45:16 +0200
Samuel Thibault sthiba...@debian.org wrote:
Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
Maybe it can be trimmed a bit more, but that's still 239 unique
dependencies.
❦ 28 août 2015 10:32 +0100, Neil Williams codeh...@debian.org :
I still find it hard to believe that *so* much code is required to
minify JS. The excuse that JS is moving fast is nonsense. The reality
would appear to be that nobody actually *cares* about the mess, they
just use it.
It's a
❦ 28 août 2015 12:03 +0200, Samuel Thibault sthiba...@debian.org :
I wonder why mere gzip compression is not used. Don't all browsers
support Accept-Compress: gzip?
Minification saves some additional bytes. About 10% (when gzipped).
--
If you tell the truth you don't have to remember
Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
Maybe it can be trimmed a bit more, but that's still 239 unique
dependencies.
Note that you don't have to make that 239 debian packages, you could as
well just ship them all in one package, as long as the whole code passes
NEW, i.e.
Vincent Bernat, le Fri 28 Aug 2015 10:48:28 +0200, a écrit :
❦ 28 août 2015 10:29 +0200, Samuel Thibault sthiba...@debian.org :
What will happen is that maintainers will fallback to the second less
horrible solution and cripple the package (by using an older version of
the JS lib for
Dmitry Smirnov only...@debian.org writes:
On Monday 24 August 2015 13:54:21 Simon Josefsson wrote:
I believe the blog post below has relevance to Debian's stance on
including minified JavaScript in packages:
https://zyan.scripts.mit.edu/blog/backdooring-js/
Thank you for a nice argument
❦ 28 août 2015 08:22 +0100, Philip Hands p...@hands.com :
Or alternatively, by packaging the minifier that is being used with the
package
that needs it. Yes, that's a horrible idea with lots of code duplication,
but
if I understand the problem, every JS file must be minified with the
Vincent Bernat, le Fri 28 Aug 2015 07:42:42 +0200, a écrit :
Yes, that is a danger. I think putting those things in contrib should be a
good solution if rebuilding is such a big problem. Because if it is, the
code
really really doesn't belong in main.
What will happen is that
Vincent Bernat wrote:
(...)
It has already been said numerous time in the past, for some Javascript
code, we don't really have the tools in Debian to easily go from the
source to the minified version. It's possible, but without the
appropriate tools, it's painful.
I've been using
On Fri, Aug 28, 2015 at 10:06:17AM +0200, Vincent Bernat wrote:
❦ 28 août 2015 08:22 +0100, Philip Hands p...@hands.com :
Or alternatively, by packaging the minifier that is being used with the
package
that needs it. Yes, that's a horrible idea with lots of code
duplication, but
Russ Allbery wrote:
Neil Williams codeh...@debian.org writes:
Usable software needs usable tools.
The problem is that this *is* usable for nearly all the people who
currently use it, who just run one command to install it and have all
those dependencies pulled from a remote repo for them.
On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère nir...@debian.org
wrote:
Vincent Bernat wrote:
(...)
It has already been said numerous time in the past, for some Javascript
code, we don't really have the tools in Debian to easily go from the
source to the minified version. It's
Neil Williams codeh...@debian.org writes:
I still find it hard to believe that *so* much code is required to
minify JS. The excuse that JS is moving fast is nonsense. The reality
would appear to be that nobody actually *cares* about the mess, they
just use it.
This is almost certainly
On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère nir...@debian.org
wrote:
Vincent Bernat wrote:
(...)
It has already been said numerous time in the past, for some Javascript
code, we don't really have the tools in Debian to easily go from the
source to the minified version. It's
1 - 100 of 147 matches
Mail list logo