Hey, all. So, I'm looking at packaging tt-rss - an RSS reader implemented as a PHP webapp - for Fedora, since I run it on my own server. It became rapidly clear that it's a landmine of bundled PHP libraries and snippets and uncertain licensing. I'm unsure which of the things it bundles would be likely to qualify as copylibs, and also a few of the things it bundles seem to raise wider questions, so I thought I'd post my 'deps list' here and raise some of the issues:
* dojo/dijit - F/OSS, packaged
* simplepie - F/OSS, packaged
* CheckBoxTree.js - requires formal license, unpackaged - http://www.thejekels.com/blog/dojo/dijit-tree-with-multi-state-checkboxes/co... . not entirely sure whether this would count as a copylib.
* htmlpurifier - F/OSS, unpackaged but its PEAR channel is packaged as php-channel-htmlpurifier, review at https://bugzilla.redhat.com/show_bug.cgi?id=542045
* iui - F/OSS, unpackaged - https://code.google.com/p/iui/
* MiniTemplator - F/OSS, unpackaged - http://www.source-code.biz/MiniTemplator/
* phpmailer - F/OSS, packaged
* position.js - comprises http://codesnippets.joyent.com/posts/show/835 and http://codesnippets.joyent.com/posts/show/836 - unlicensed, author contacted - these are probably copylibs?
* prototypejs - F/OSS, unpackaged, already embedded in many other packages - https://bugzilla.redhat.com/show_bug.cgi?id=523277
* php-pubsubhubbub - F/OSS, unpackaged: https://code.google.com/p/pubsubhubbub/ (was https://code.google.com/p/pubsubhubbub-php/ , merged into upstream)
* scriptaculous - F/OSS, mostly unpackaged, but part of http://pypi.python.org/pypi/Scriptaculous , which is a python wrapper with old versions of scriptaculous and prototype embedded in it
* sphinxapi.php - F/OSS, packaged (sphinx-php)
* tmhoauth - F/OSS, unpackaged - https://github.com/themattharris/tmhOAuth
* xsl_mop-up.js - public domain, unpackaged - http://www.fadshop.net/xsl_mop-up.js but link is dead, ref https://bugzilla.mozilla.org/show_bug.cgi?id=98168 . probably a copylib
So the major issues that come up: prototypejs seems to be embedded into an awful lot of Fedora packages, if you look at https://bugzilla.redhat.com/show_bug.cgi?id=523277 as a reference. mediatomb has a copy, wordpress has a copy, python-webhelpers has a copy (actually it seems it's not there any more), python-Scriptaculous has a copy, asterisk has a copy. Isn't this a major issue? Should I file a bug for this and try to split prototypejs out into a single package which all those other packages could depend on, or am I missing something? Has it been declared a copylib? wordpress review request does not appear to have dealt with it, stating "* no shared libraries are present: okay" - I don't know if it was missed, or wasn't present in wordpress at the time of review. mediatomb review similarly didn't catch it.
python-Scriptaculous seems to be a python (TurboGears) wrapper for scriptaculous, and it has scriptaculous and prototypejs embedded in it. the review request doesn't seem to have dealt with this at all, it simply states "+ no headers or static libraries.", which seems to be, well, a bit of a porky. =) https://bugzilla.redhat.com/show_bug.cgi?id=508510 . should I raise this as a bug, or again, am I missing something?
If anyone clueful has thoughts on the prototypejs and python-scriptaculous issues, or on which of the tt-rss deps are likely copylibs and don't need to be packaged separately, that'd be really helpful. thanks!
Speaking about prototype and scriptaculous, I am sure that they are bundled also in Rails and if there are some Rails applications packaged, they will be included also in them. However I am not sure if they should be packaged separately or just copylibs.
Vit
Dne 31.8.2011 06:35, Adam Williamson napsal(a):
Hey, all. So, I'm looking at packaging tt-rss - an RSS reader implemented as a PHP webapp - for Fedora, since I run it on my own server. It became rapidly clear that it's a landmine of bundled PHP libraries and snippets and uncertain licensing. I'm unsure which of the things it bundles would be likely to qualify as copylibs, and also a few of the things it bundles seem to raise wider questions, so I thought I'd post my 'deps list' here and raise some of the issues:
dojo/dijit - F/OSS, packaged
simplepie - F/OSS, packaged
CheckBoxTree.js - requires formal license, unpackaged -
http://www.thejekels.com/blog/dojo/dijit-tree-with-multi-state-checkboxes/co... . not entirely sure whether this would count as a copylib.
- htmlpurifier - F/OSS, unpackaged but its PEAR channel is packaged as
php-channel-htmlpurifier, review at https://bugzilla.redhat.com/show_bug.cgi?id=542045
iui - F/OSS, unpackaged - https://code.google.com/p/iui/
MiniTemplator - F/OSS, unpackaged -
http://www.source-code.biz/MiniTemplator/
phpmailer - F/OSS, packaged
position.js - comprises http://codesnippets.joyent.com/posts/show/835
and http://codesnippets.joyent.com/posts/show/836 - unlicensed, author contacted - these are probably copylibs?
- prototypejs - F/OSS, unpackaged, already embedded in many other
packages - https://bugzilla.redhat.com/show_bug.cgi?id=523277
- php-pubsubhubbub - F/OSS, unpackaged:
https://code.google.com/p/pubsubhubbub/ (was https://code.google.com/p/pubsubhubbub-php/ , merged into upstream)
- scriptaculous - F/OSS, mostly unpackaged, but part of
http://pypi.python.org/pypi/Scriptaculous , which is a python wrapper with old versions of scriptaculous and prototype embedded in it
sphinxapi.php - F/OSS, packaged (sphinx-php)
tmhoauth - F/OSS, unpackaged -
https://github.com/themattharris/tmhOAuth
- xsl_mop-up.js - public domain, unpackaged -
http://www.fadshop.net/xsl_mop-up.js but link is dead, ref https://bugzilla.mozilla.org/show_bug.cgi?id=98168 . probably a copylib
So the major issues that come up: prototypejs seems to be embedded into an awful lot of Fedora packages, if you look at https://bugzilla.redhat.com/show_bug.cgi?id=523277 as a reference. mediatomb has a copy, wordpress has a copy, python-webhelpers has a copy (actually it seems it's not there any more), python-Scriptaculous has a copy, asterisk has a copy. Isn't this a major issue? Should I file a bug for this and try to split prototypejs out into a single package which all those other packages could depend on, or am I missing something? Has it been declared a copylib? wordpress review request does not appear to have dealt with it, stating "* no shared libraries are present: okay" - I don't know if it was missed, or wasn't present in wordpress at the time of review. mediatomb review similarly didn't catch it.
python-Scriptaculous seems to be a python (TurboGears) wrapper for scriptaculous, and it has scriptaculous and prototypejs embedded in it. the review request doesn't seem to have dealt with this at all, it simply states "+ no headers or static libraries.", which seems to be, well, a bit of a porky. =) https://bugzilla.redhat.com/show_bug.cgi?id=508510 . should I raise this as a bug, or again, am I missing something?
If anyone clueful has thoughts on the prototypejs and python-scriptaculous issues, or on which of the tt-rss deps are likely copylibs and don't need to be packaged separately, that'd be really helpful. thanks!
From : https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_li...
"At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future."
This explain why so much .js libraries are bundled in so much wedapps.
Remi.
----- Mail original -----
Speaking about prototype and scriptaculous, I am sure that they are bundled also in Rails and if there are some Rails applications packaged, they will be included also in them. However I am not sure if they should be packaged separately or just copylibs.
Vit
Dne 31.8.2011 06:35, Adam Williamson napsal(a):
Hey, all. So, I'm looking at packaging tt-rss - an RSS reader implemented as a PHP webapp - for Fedora, since I run it on my own server. It became rapidly clear that it's a landmine of bundled PHP libraries and snippets and uncertain licensing. I'm unsure which of the things it bundles would be likely to qualify as copylibs, and also a few of the things it bundles seem to raise wider questions, so I thought I'd post my 'deps list' here and raise some of the issues:
dojo/dijit - F/OSS, packaged
simplepie - F/OSS, packaged
CheckBoxTree.js - requires formal license, unpackaged -
http://www.thejekels.com/blog/dojo/dijit-tree-with-multi-state-checkboxes/co... . not entirely sure whether this would count as a copylib.
- htmlpurifier - F/OSS, unpackaged but its PEAR channel is packaged
as php-channel-htmlpurifier, review at https://bugzilla.redhat.com/show_bug.cgi?id=542045
iui - F/OSS, unpackaged - https://code.google.com/p/iui/
MiniTemplator - F/OSS, unpackaged -
http://www.source-code.biz/MiniTemplator/
phpmailer - F/OSS, packaged
position.js - comprises
http://codesnippets.joyent.com/posts/show/835 and http://codesnippets.joyent.com/posts/show/836 - unlicensed, author contacted - these are probably copylibs?
- prototypejs - F/OSS, unpackaged, already embedded in many other
packages - https://bugzilla.redhat.com/show_bug.cgi?id=523277
- php-pubsubhubbub - F/OSS, unpackaged:
https://code.google.com/p/pubsubhubbub/ (was https://code.google.com/p/pubsubhubbub-php/ , merged into upstream)
- scriptaculous - F/OSS, mostly unpackaged, but part of
http://pypi.python.org/pypi/Scriptaculous , which is a python wrapper with old versions of scriptaculous and prototype embedded in it
sphinxapi.php - F/OSS, packaged (sphinx-php)
tmhoauth - F/OSS, unpackaged -
https://github.com/themattharris/tmhOAuth
- xsl_mop-up.js - public domain, unpackaged -
http://www.fadshop.net/xsl_mop-up.js but link is dead, ref https://bugzilla.mozilla.org/show_bug.cgi?id=98168 . probably a copylib
So the major issues that come up: prototypejs seems to be embedded into an awful lot of Fedora packages, if you look at https://bugzilla.redhat.com/show_bug.cgi?id=523277 as a reference. mediatomb has a copy, wordpress has a copy, python-webhelpers has a copy (actually it seems it's not there any more), python-Scriptaculous has a copy, asterisk has a copy. Isn't this a major issue? Should I file a bug for this and try to split prototypejs out into a single package which all those other packages could depend on, or am I missing something? Has it been declared a copylib? wordpress review request does not appear to have dealt with it, stating "* no shared libraries are present: okay" - I don't know if it was missed, or wasn't present in wordpress at the time of review. mediatomb review similarly didn't catch it.
python-Scriptaculous seems to be a python (TurboGears) wrapper for scriptaculous, and it has scriptaculous and prototypejs embedded in it. the review request doesn't seem to have dealt with this at all, it simply states "+ no headers or static libraries.", which seems to be, well, a bit of a porky. =) https://bugzilla.redhat.com/show_bug.cgi?id=508510 . should I raise this as a bug, or again, am I missing something?
If anyone clueful has thoughts on the prototypejs and python-scriptaculous issues, or on which of the tt-rss deps are likely copylibs and don't need to be packaged separately, that'd be really helpful. thanks!
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 2011-08-31 at 07:52 +0200, Remi wrote:
From : https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_li...
"At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future."
This explain why so much .js libraries are bundled in so much wedapps.
Ah, thanks. I missed that. Still, it seems bad to be duplicating some very popular js quite so much:
[root@adam lib]# repoquery -f */prototype.js rubygem-thin-doc-0:1.2.11-3.fc16.x86_64 rubygem-railties-0:3.0.9-2.fc16.noarch rt3-0:3.8.10-4.fc16.noarch rubygem-json_pure-doc-0:1.5.1-1.fc16.noarch zabbix-web-0:1.8.6-1.fc16.noarch frepple-0:0.8.1-4.fc16.x86_64 rubygem-scruffy-doc-0:0.2.6-2.fc15.noarch zikula-0:1.2.3-2.fc15.noarch rubygem-gettext_rails-doc-0:2.1.0-3.fc14.noarch rubygem-railties-0:3.0.10-1.fc16.noarch horde-0:3.3.11-2.fc15.noarch turba-0:2.3.5-2.fc15.noarch rubygem-actionpack-1:3.0.10-1.fc16.noarch WebCalendar-0:1.2.3-4.fc16.noarch pnp4nagios-0:0.4.14-5.fc15.x86_64 frepple-0:0.8.1-4.fc16.i686 dogtag-pki-tps-theme-0:9.0.6-1.fc16.noarch mantis-0:1.2.4-2.fc15.noarch imp-0:4.3.9-2.fc15.noarch wordpress-0:3.2.1-2.fc16.noarch mediatomb-0:0.12.1-12.fc16.x86_64 mythweb-0:0.24.1-1.fc15.x86_64 rubygem-shoulda-doc-0:2.11.3-1.fc15.noarch rubygem-calendar_date_select-0:1.15-4.fc13.noarch rubygem-locale_rails-doc-0:2.0.5-7.fc15.noarch ingo-0:1.2.5-1.fc15.noarch rubygem-json-doc-0:1.4.6-3.fc15.x86_64 smokeping-0:2.4.2-12.fc15.noarch kronolith-0:2.3.4-2.fc15.noarch asterisk-0:1.8.5.0-1.fc16.2.x86_64 rubygem-activeldap-doc-0:1.2.2-2.fc15.noarch wordpress-0:3.2.1-2.fc16.noarch zabbix-web-0:1.8.6-1.fc16.noarch python-Scriptaculous-0:1.8.2-6.fc15.noarch rubygem-actionpack-1:3.0.9-1.fc16.noarch
erk.
Still, it means for now I only need to worry about the PHP stuff...
On Tue, 2011-08-30 at 23:46 -0700, Adam Williamson wrote:
On Wed, 2011-08-31 at 07:52 +0200, Remi wrote:
From : https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_li...
"At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future."
This explain why so much .js libraries are bundled in so much wedapps.
Ah, thanks. I missed that. Still, it seems bad to be duplicating some very popular js quite so much:
[root@adam lib]# repoquery -f */prototype.js
.....many.....
# repoquery -f '*/jquery*.js' --qf="%{NAME}\n" | sort | uniq | wc -l 356
jQuery FTW :)
ons 2011-08-31 klockan 10:17 +0300 skrev Yanko Kaneti:
# repoquery -f '*/jquery*.js' --qf="%{NAME}\n" | sort | uniq | wc -l 356
jQuery FTW :)
Most of these are probably doxygen generated documentation. Recent versions of doxygen provides a search option for the generated html documentation and a copy of jquery.js.
At the moment jquery is not package as a separate package. If it was packagers could replace them with a symlink to that.
Mattias
Dne 31.8.2011 13:12, Mattias Ellert napsal(a):
At the moment jquery is not package as a separate package. If it was packagers could replace them with a symlink to that.
Help us to finish https://bugzilla.redhat.com/show_bug.cgi?id=nodejs and you can get https://bugzilla.redhat.com/show_bug.cgi?id=457343 finished as well ;)
Matěj
On Tue, Aug 30, 2011 at 11:46:36PM -0700, Adam Williamson wrote:
On Wed, 2011-08-31 at 07:52 +0200, Remi wrote:
From : https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_li...
"At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future."
This explain why so much .js libraries are bundled in so much wedapps.
Ah, thanks. I missed that. Still, it seems bad to be duplicating some very popular js quite so much:
Actually, it makes perfect sense. Different frameworks release versions with different versions of jQuery or prototype. Trying to force all those packages to play nice with a single system-wide library is hell.
Just imagine the scenario where, say, rails wants to ship version 1.1.5 but there's a security patch in Django that relies on 1.2.1 and they are not backwards compatible.
There's no hard-set rule of "how big a file has to be to be considered for packaging on its own" afaik but I'd say these are copylibs with good reason.
[root@adam lib]# repoquery -f */prototype.js rubygem-thin-doc-0:1.2.11-3.fc16.x86_64 rubygem-railties-0:3.0.9-2.fc16.noarch rt3-0:3.8.10-4.fc16.noarch rubygem-json_pure-doc-0:1.5.1-1.fc16.noarch zabbix-web-0:1.8.6-1.fc16.noarch frepple-0:0.8.1-4.fc16.x86_64 rubygem-scruffy-doc-0:0.2.6-2.fc15.noarch zikula-0:1.2.3-2.fc15.noarch rubygem-gettext_rails-doc-0:2.1.0-3.fc14.noarch rubygem-railties-0:3.0.10-1.fc16.noarch horde-0:3.3.11-2.fc15.noarch turba-0:2.3.5-2.fc15.noarch rubygem-actionpack-1:3.0.10-1.fc16.noarch WebCalendar-0:1.2.3-4.fc16.noarch pnp4nagios-0:0.4.14-5.fc15.x86_64 frepple-0:0.8.1-4.fc16.i686 dogtag-pki-tps-theme-0:9.0.6-1.fc16.noarch mantis-0:1.2.4-2.fc15.noarch imp-0:4.3.9-2.fc15.noarch wordpress-0:3.2.1-2.fc16.noarch mediatomb-0:0.12.1-12.fc16.x86_64 mythweb-0:0.24.1-1.fc15.x86_64 rubygem-shoulda-doc-0:2.11.3-1.fc15.noarch rubygem-calendar_date_select-0:1.15-4.fc13.noarch rubygem-locale_rails-doc-0:2.0.5-7.fc15.noarch ingo-0:1.2.5-1.fc15.noarch rubygem-json-doc-0:1.4.6-3.fc15.x86_64 smokeping-0:2.4.2-12.fc15.noarch kronolith-0:2.3.4-2.fc15.noarch asterisk-0:1.8.5.0-1.fc16.2.x86_64 rubygem-activeldap-doc-0:1.2.2-2.fc15.noarch wordpress-0:3.2.1-2.fc16.noarch zabbix-web-0:1.8.6-1.fc16.noarch python-Scriptaculous-0:1.8.2-6.fc15.noarch rubygem-actionpack-1:3.0.9-1.fc16.noarch
erk.
Still, it means for now I only need to worry about the PHP stuff...
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Aug 31, 2011 at 08:23:56AM -0700, Jorge Gallegos wrote:
On Tue, Aug 30, 2011 at 11:46:36PM -0700, Adam Williamson wrote:
On Wed, 2011-08-31 at 07:52 +0200, Remi wrote:
From : https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_li...
"At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future."
This explain why so much .js libraries are bundled in so much wedapps.
Ah, thanks. I missed that. Still, it seems bad to be duplicating some very popular js quite so much:
Actually, it makes perfect sense. Different frameworks release versions with different versions of jQuery or prototype. Trying to force all those packages to play nice with a single system-wide library is hell.
Just imagine the scenario where, say, rails wants to ship version 1.1.5 but there's a security patch in Django that relies on 1.2.1 and they are not backwards compatible.
You could make the same argument for any library, and it would be just as wrong.
Benefits from packaging Javascript once:
- if there's a security problem, you just have to fix and update one package
- no questions about "is the security problem fixed in <this random javascript file>"?
- we can probably arrange it so that users of different web apps only download the javascript file once
- no extra copies on disk
Rich.
On Wed, Aug 31, 2011 at 09:47, Richard W.M. Jones rjones@redhat.com wrote:
On Wed, Aug 31, 2011 at 08:23:56AM -0700, Jorge Gallegos wrote:
On Tue, Aug 30, 2011 at 11:46:36PM -0700, Adam Williamson wrote:
On Wed, 2011-08-31 at 07:52 +0200, Remi wrote:
From : https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_li...
"At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future."
This explain why so much .js libraries are bundled in so much wedapps.
Ah, thanks. I missed that. Still, it seems bad to be duplicating some very popular js quite so much:
Actually, it makes perfect sense. Different frameworks release versions with different versions of jQuery or prototype. Trying to force all those packages to play nice with a single system-wide library is hell.
Just imagine the scenario where, say, rails wants to ship version 1.1.5 but there's a security patch in Django that relies on 1.2.1 and they are not backwards compatible.
You could make the same argument for any library, and it would be just as wrong.
Benefits from packaging Javascript once:
- if there's a security problem, you just have to fix and update one package
- no questions about "is the security problem fixed in <this random javascript file>"?
- we can probably arrange it so that users of different web apps only download the javascript file once
- no extra copies on disk
Rich.
Here is the problem in a nutshell. The upstreams for all this will not give a rats ass about using a system wide jquery because it does not solve their problem.
Their problem is that the majority of their users are going to be grabbing pages from "smart" phones which aren't smart and will gladly download the same data over and over again because they are built to use as much bandwidth as possible so the user gets charged for data caps. Also you know that 99% of your customers only really get full bandwidth if their phone if they stand next to a tower with the phone plugged into a charger.. otherwise they get crap for bandwidth even at 5 bars.
So you make sure your javascripts aren't the full score 100k monstrosities but are just what you need to get the page to work. So those 80 copies of jquery we have aren't going to be the same even if they all came from the same version of upstream jquery. And delivering just one large jquery that can be used is not going to fit what either upstreams, web developers OR their users want or need.
And yes I know, we can say all of the above for anything else and show how it is wrong for all those cases. Unlike math, the real world doesn't care and finding a counter example does not invalidate the reason it is true in some place.
Dne 31.8.2011 19:31, Stephen John Smoogen napsal(a):
they all came from the same version of upstream jquery. And delivering just one large jquery that can be used is not going to fit what either upstreams, web developers OR their users want or need.
I still haven't got the reason why jQuery cannot be “compiled” from the source as any other source code? Why do you still talk about large monstrosities? Nobody requires that.
Matěj
On Wed, 2011-08-31 at 19:35 +0200, Matej Cepl wrote:
Dne 31.8.2011 19:31, Stephen John Smoogen napsal(a):
they all came from the same version of upstream jquery. And delivering just one large jquery that can be used is not going to fit what either upstreams, web developers OR their users want or need.
I still haven't got the reason why jQuery cannot be “compiled” from the source as any other source code? Why do you still talk about large monstrosities? Nobody requires that.
often web apps only use one or two functions ripped out of a much larger 'library' - all of those packages which have bits of jquery in them are unlikely to have *all* of jquery in them, and they probably don't have the same little chunks.
I think this applies less to prototypejs, though: it's a single file, and when I checked quickly, all the packages I looked at seemed to have more or less the same version of it. I can do a more careful evaluation if I get a bit of time, though, and see how much variance there really is in the prototype.js files in all those packages.
jquery, at least, claims a very strong security history, with only one fairly minor vulnerability. prototype.js has had at least one significant vuln, as that bug link I put in my original mail shows.
On Wed, Aug 31, 2011 at 10:49:09AM -0700, Adam Williamson wrote:
On Wed, 2011-08-31 at 19:35 +0200, Matej Cepl wrote:
Dne 31.8.2011 19:31, Stephen John Smoogen napsal(a):
they all came from the same version of upstream jquery. And delivering just one large jquery that can be used is not going to fit what either upstreams, web developers OR their users want or need.
I still haven't got the reason why jQuery cannot be “compiled” from the source as any other source code? Why do you still talk about large monstrosities? Nobody requires that.
often web apps only use one or two functions ripped out of a much larger 'library' - all of those packages which have bits of jquery in them are unlikely to have *all* of jquery in them, and they probably don't have the same little chunks.
I think this applies less to prototypejs, though: it's a single file, and when I checked quickly, all the packages I looked at seemed to have more or less the same version of it. I can do a more careful evaluation if I get a bit of time, though, and see how much variance there really is in the prototype.js files in all those packages.
jquery, at least, claims a very strong security history, with only one fairly minor vulnerability. prototype.js has had at least one significant vuln, as that bug link I put in my original mail shows.
Hmmm...I'm not so sure about the assertion that people are ripping apart jquery in specific hold up. Does someone have numbers? I'm quite willing to bet that of the copies of jquery on Fedora, most of them are not a subset of jquery's core because most of them are not going to be used in web applications. Someone mentioned doxygen earlier and python-sphinx generated docs also follows this.
(I notice that python-sphinx and the docs generated using it are using a minified version of jquery :-( Since we don't have a jsmin'er in Fedora atm, that means jquery in all these packages is not being created from source :-( )
For actual web apps, I'm also not sure that we'll find that the javascript has been amputated. Most of the js libraries are 1) fairly interconnected in terms of the functions they use to provide the functionality you use, 2) are intentionally kept to some sort of "core" size 3) are shipped in a minified form as well as having easier to work on source 4) using CDN's are becoming much more prevalent.
Real numbers before bald assertions please :-)
-Toshio
On Wed, Aug 31, 2011 at 15:52, Toshio Kuratomi a.badger@gmail.com wrote:
Real numbers before bald assertions please :-)
Sorry I thought this was devel@lists.fedoraproject.org where fact was not needed and very much disdained :)
I realized I have jumped onto the hype train of javascript programming where supposedly it is best practice to "never ship a full JS when you only need X". So I take back my assertions.
On Wed, 2011-08-31 at 14:52 -0700, Toshio Kuratomi wrote:
Real numbers before bald assertions please :-)
I resign!
On Tue, Aug 30, 2011 at 09:35:50PM -0700, Adam Williamson wrote:
- dojo/dijit - F/OSS, packaged
Currently for any javascript library you are allowed to bundle. In the future this may not be the case so you may have a lot of work to do to maintain this application in the future. Note that no one has currently stepped forward to work on the JavaScript Guidelines in the several years since I stopped looking at it, so that "future" day may be a long time in coming.
Here's the draft that I wrote several years ago: http://fedoraproject.org/wiki/JavaScript_libraries_packaging_guideline_draft
Note that I'm unhappy with it. After working on web apps for a while I think it would be better to model the guidelines after the static library guidelines than dynamic libraries. that would mean that we'd package the javascript libraries in their own packages. Then, as part of building the web application packages, you would BuildRequire the javascript library and copy the javascript code into the application package. You, as a packager, would still have the burden of deciding whether to port applications to newer versions of a library as they came out (if upstream wasn't proactive about this) or creating and maintaining a compat- package with the old version of the javascript library for you to build against. But this would help with the questions of how to specify where a javascript library was located in the url hierarchy, prevent breakage if a javascript library was upgraded incompatibly in the middle of a release, etc.
-Toshio
-
Adam Williamson -
Jorge Gallegos -
Matej Cepl -
Mattias Ellert -
Remi Collet -
Richard W.M. Jones -
Stephen John Smoogen -
Toshio Kuratomi -
Vít Ondruch -
Yanko Kaneti