FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-26-2011, 10:29 PM
Zygmunt Krynicki
 
Default Dealing with embedded javascript libraries

W dniu 24.10.2011 01:20, Ben Finney pisze:

I would very much like that to change – that programmers should expect a
single instance of a Javascript library to be useable across the OS, and
that a Javascript library without a dependable ABI should be shunned by
most application writers, and for applications to declare the library
versions they expect in a standardised, automated way. But I don't know
what to do to get there.


Hi.

I'd like to throw a few comments here. I speak both as an web
application developer, debian packager (well, packaging my application
for debian-based systems) and deployment/ops engineer.


Asking for this is *highly* unrealistic and will only further alienate
developers from Debian's way of doing things. Current best practice is
to use CDNs that distribute a particular or latest version of a library
(jQuery for example has several such networks available) or to bundle
the library directly.


The reason for this is simple: quality control and portability (across
hosting systems)


Another thing to point out is that unlike traditional applications where
linking is explicit and done before actual startup here the linking
happens at another machine, the one of the user of the web application.
The actual library can come from a yet another system. The key issue to
point out here is that this is not really linking the way we think about
it. Here it is not code but data.


If anything, having one version of a javascript library *hurts*
Debian-as-a-platform. I would encourage a different approach altogether:
explicit mutli-versioning (ideally for all upstream releases or for all
upstream releases that are known to introduce features and are not
emergency bug/security fixes) and explicit version dependency that
matches upstream. That later requirement may be ignored if uptream is
not responding or the application is known to work correctly with
another version of a library.


This approach will allow web application developers to use Debian in the
way they expect systems to work.


At the end of the day I cannot use Debian's jQuery because I must
control what goes out to ensure quality. Multiply this problem by
co-hosting many applications and you get the answer.


As long what I described above is the prevailing point of view or
motivation of web application developers then packaged javascript
libraries will only fill a niche where someone deploys a packaged
wiki/bug tracker/something else for their small team/co workers.


More complicated web applications will be deployed outside the packaging
system, without any reuse of packaged libraries, without any advantages
that Debian brings to the table.


Thanks
Zygmunt Krynicki

PS: re-sending from subscribed email, if you get a dupe please excuse me.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EA889CB.4070109@canonical.com">http://lists.debian.org/4EA889CB.4070109@canonical.com
 
Old 10-26-2011, 10:46 PM
Michael Gilbert
 
Default Dealing with embedded javascript libraries

On Wed, Oct 26, 2011 at 6:29 PM, Zygmunt Krynicki wrote:
> If anything, having one version of a javascript library *hurts*
> Debian-as-a-platform. I would encourage a different approach altogether:
> explicit mutli-versioning (ideally for all upstream releases or for all
> upstream releases that are known to introduce features and are not emergency
> bug/security fixes) and explicit version dependency that matches upstream.
> That later requirement may be ignored if uptream is not responding or the
> application is known to work correctly with another version of a library.

There isn't any real technical factor limiting the number of versions
to one. Theoretically, there could both jquery1.4 and jquery1.6
source packages coexisting (as long as the binary files are
appropriately versioned as well). Thus if wordpress only works with
1.4, then it can use that temporarily until it gets updated to support
1.6 (or whatever the problem it was that started this discussion).

Anyway, it's all solvable (given volunteers actually interested in
doing the work to do it).

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANTw=MOZQNeauKuGZDvf1EOWPCmt9DGLarqWrkWm3_3W-WKw9A@mail.gmail.com">http://lists.debian.org/CANTw=MOZQNeauKuGZDvf1EOWPCmt9DGLarqWrkWm3_3W-WKw9A@mail.gmail.com
 
Old 10-26-2011, 10:55 PM
Zygmunt Krynicki
 
Default Dealing with embedded javascript libraries

W dniu 27.10.2011 00:46, Michael Gilbert pisze:

On Wed, Oct 26, 2011 at 6:29 PM, Zygmunt Krynicki wrote:

If anything, having one version of a javascript library *hurts*
Debian-as-a-platform. I would encourage a different approach altogether:
explicit mutli-versioning (ideally for all upstream releases or for all
upstream releases that are known to introduce features and are not emergency
bug/security fixes) and explicit version dependency that matches upstream.
That later requirement may be ignored if uptream is not responding or the
application is known to work correctly with another version of a library.


There isn't any real technical factor limiting the number of versions
to one. Theoretically, there could both jquery1.4 and jquery1.6
source packages coexisting (as long as the binary files are
appropriately versioned as well). Thus if wordpress only works with
1.4, then it can use that temporarily until it gets updated to support
1.6 (or whatever the problem it was that started this discussion).

Anyway, it's all solvable (given volunteers actually interested in
doing the work to do it).


Is there anyone that would like to mentor me for a while to help me get
started? I'm quite interested in solving this problem.


Best regards
Zygmunt Krynicki


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EA88FFE.3030003@canonical.com">http://lists.debian.org/4EA88FFE.3030003@canonical.com
 
Old 10-26-2011, 10:59 PM
Zygmunt Krynicki
 
Default Dealing with embedded javascript libraries

W dniu 27.10.2011 00:29, Zygmunt Krynicki pisze:

W dniu 24.10.2011 01:20, Ben Finney pisze:

I would very much like that to change – that programmers should expect a
single instance of a Javascript library to be useable across the OS, and
that a Javascript library without a dependable ABI should be shunned by
most application writers, and for applications to declare the library
versions they expect in a standardised, automated way. But I don't know
what to do to get there.


Hi.

I'd like to throw a few comments here. I speak both as an web



Another thing to point out is that unlike traditional applications where
linking is explicit and done before actual startup here the linking
happens at another machine, the one of the user of the web application.
The actual library can come from a yet another system. The key issue to
point out here is that this is not really linking the way we think about
it. Here it is not code but data.


Replying to myself, this obviously does not include server-side
javascript libraries for things like nodejs. Perhaps we should
explicitly differentiate those?


Best regards
ZK


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EA890E5.10906@canonical.com">http://lists.debian.org/4EA890E5.10906@canonical.com
 
Old 10-26-2011, 11:28 PM
Ian Jackson
 
Default Dealing with embedded javascript libraries

Michael Gilbert writes ("Re: Dealing with embedded javascript libraries"):
> There isn't any real technical factor limiting the number of versions
> to one. Theoretically, there could both jquery1.4 and jquery1.6
> source packages coexisting (as long as the binary files are
> appropriately versioned as well). Thus if wordpress only works with
> 1.4, then it can use that temporarily until it gets updated to support
> 1.6 (or whatever the problem it was that started this discussion).

The difficulty is that if we end up with ten different versions of
some random javascript library, when it turns out to have a security
vulnerability we need to somehow backport the patch to each of those
ten versions.

And here "we" means the security team, not the people who uploaded the
ten versions in the first place.

So this is rather unpalatable.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20136.38836.832796.412159@chiark.greenend.org.uk"> http://lists.debian.org/20136.38836.832796.412159@chiark.greenend.org.uk
 
Old 10-26-2011, 11:52 PM
Michael Gilbert
 
Default Dealing with embedded javascript libraries

On Wed, Oct 26, 2011 at 6:55 PM, Zygmunt Krynicki wrote:
> Is there anyone that would like to mentor me for a while to help me get
> started? I'm quite interested in solving this problem.

You can certainly work on anything in Debian (including this) and
present your work to mentors [0] and/or the maintainers of the
package.

Best wishes,
Mike

[0] http://mentors.debian.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANTw=MOgQF6o5Vj-xHQ6KQhcNCfJMpCP48kAu=1-vaSMQpWdyw@mail.gmail.com">http://lists.debian.org/CANTw=MOgQF6o5Vj-xHQ6KQhcNCfJMpCP48kAu=1-vaSMQpWdyw@mail.gmail.com
 
Old 10-27-2011, 04:36 AM
Paul Wise
 
Default Dealing with embedded javascript libraries

On Thu, Oct 27, 2011 at 7:28 AM, Ian Jackson wrote:

> The difficulty is that if we end up with ten different versions of
> some random javascript library, when it turns out to have a security
> vulnerability we need to somehow backport the patch to each of those
> ten versions.
>
> And here "we" means the security team, not the people who uploaded the
> ten versions in the first place.

I would assume the security team would just file bugs and let the
maintainer deal with it, unless the issue is embargoed?

> So this is rather unpalatable.

Agreed with that part.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKTje6HPVjkcLdnKv9zLMcab=L3m63ogSp7OtiA-V=jvCpLgcA@mail.gmail.com">http://lists.debian.org/CAKTje6HPVjkcLdnKv9zLMcab=L3m63ogSp7OtiA-V=jvCpLgcA@mail.gmail.com
 
Old 10-31-2011, 04:42 PM
Jakub Wilk
 
Default Dealing with embedded javascript libraries

* Raphael Hertzog <hertzog@debian.org>, 2011-10-26, 18:47:
For instance I just noticed that we can't install new widgets with
the current wordpress package due to some javascript related problem.
I'm not familiar enough with the codebase to investigate it easily. I
can't ask upstream about it because it works with the version of the
libraries that they are shipping.

Why you can't? Do they bite if you do?


For the very same reason we don't like Ubuntu bugs that have not been
reproduced on Debian.


If the bug looks like "foo doesn't work on Ubuntu!!1one", then indeed it
won't be welcome. Even if I wanted to help the poor little user, surely
I won't bother to install Ubuntu to debug the problem.


On the other hand, I do appreciate "If you upgrade baz to 3.14 and turn
on quux (incidentally, this is what we did in Ubuntu), foo explodes"
bugs. This is something I can try to reproduce in a (modified) Debian
environment. And maybe it's something worth fixing, because some day
Debian will have baz 3.14, and enabling quux might be not such a bad
idea after all.



That said, I acknowledge that this is delicate matter. That's why I
asked if your upstream bite.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111031174214.GB1528@jwilk.net">http://lists.debian.org/20111031174214.GB1528@jwilk.net
 
Old 10-31-2011, 05:49 PM
Pau Garcia i Quiles
 
Default Dealing with embedded javascript libraries

On Thu, Oct 27, 2011 at 1:28 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:

> The difficulty is that if we end up with ten different versions of
> some random javascript library, when it turns out to have a security
> vulnerability we need to somehow backport the patch to each of those
> ten versions.
>
> And here "we" means the security team, not the people who uploaded the
> ten versions in the first place.
>
> So this is rather unpalatable.

What's the alternative?

It seems that we only have two choices:

- Either all packages use the same version of the JavaScript library
(what we have been doing until now, which results in some packages not
working properly due to changes in the JavaScript library that
manifest only in some situations in runtime). This is essentially what
we do with C, C++, etc libraries, btw: the whole Debian is built
against the same zlib, same glibc, same libpng, etc

or

- Each package works with the upstream-bundled version of the
JavaScript library (and then we have the problem of backporting
security fixes). The advantage being we are sure the application works
as expected because it has been tested by upstream.


I'm not sure what's worse: a malfunctioning application or an insecure one.


Zygmunt's proposal of adding unit testing, etc to upstream is a noble
one but highly unrealistic, IMHO.


--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKcBokuijJu-o_W1vTMX0AYrUqSZ9cheUcOSLF3TSb3fjWxjWQ@mail.gmail. com">http://lists.debian.org/CAKcBokuijJu-o_W1vTMX0AYrUqSZ9cheUcOSLF3TSb3fjWxjWQ@mail.gmail. com
 
Old 11-01-2011, 01:50 AM
Zygmunt Krynicki
 
Default Dealing with embedded javascript libraries

W dniu 31.10.2011 14:49, Pau Garcia i Quiles pisze:

On Thu, Oct 27, 2011 at 1:28 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:


The difficulty is that if we end up with ten different versions of
some random javascript library, when it turns out to have a security
vulnerability we need to somehow backport the patch to each of those
ten versions.

And here "we" means the security team, not the people who uploaded the
ten versions in the first place.

So this is rather unpalatable.


What's the alternative?

It seems that we only have two choices:

- Either all packages use the same version of the JavaScript library
(what we have been doing until now, which results in some packages not
working properly due to changes in the JavaScript library that
manifest only in some situations in runtime). This is essentially what
we do with C, C++, etc libraries, btw: the whole Debian is built
against the same zlib, same glibc, same libpng, etc

or

- Each package works with the upstream-bundled version of the
JavaScript library (and then we have the problem of backporting
security fixes). The advantage being we are sure the application works
as expected because it has been tested by upstream.


I'm not sure what's worse: a malfunctioning application or an insecure one.


Zygmunt's proposal of adding unit testing, etc to upstream is a noble
one but highly unrealistic, IMHO.


For the record. I stated the reverse, what you described above was
proposed by someone else. I on the other hand agree that we should:


1) Ship _bundled_ libraries that upstream provides. The rationale is
that version is what upstream supports. I don't believe in our capacity
to support random applications out there better than upstreams already do.


OR

2) Have broad multi-version support (perhaps eventually at dpkg level),
package multiple versions of javascript libraries, depend on the precise
version that upstream used. The motivation for this is similar to my
previous point except that it might be, theoretically, better to support
security fixes. The more direct advantage is easier support for
incompatible, co-installable versions of a single library.


I think that security aspect is moot because failing to find a proper
package people will just revert to _not_ using dpkg for their web
deployments and the world will NOT be a single bit more secure.


Best regards
ZK


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EAF5E5B.50505@canonical.com">http://lists.debian.org/4EAF5E5B.50505@canonical.com
 

Thread Tools




All times are GMT. The time now is 01:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org