Hello everyone,
I'm drafting some Javascript Guidelines and would like some input. The current ideas are on the wiki here:: https://fedoraproject.org/wiki/PackagingDrafts/Javascript
If I don't get some feedback I'll be making some decisions based on the information there in order to have something that's ready for a vote in two weeks.
My current thoughts on positions the draft will take are::
Javascript libraries must be packaged separately from web applications. Web Applications are not allowed to include Javascript Libraries (or plugins to those libraries which have a separate upstream from the web app) but must use the system provided ones.
Javascript libraries must provide an apache conf file that will serve the library from the filesystem to clients from a specific URL. config files for other web servers are optional.
URLs for Javascript libraries should be rooted in /js/
I'm not sure whether to advocate using JsMin or similar or not.
If you don't like some of these ideas, please respond! Nothing's set in stone yet, but without your input, they will get turned into Guidelines.
-Toshio
Toshio Kuratomi wrote:
Hello everyone,
I'm drafting some Javascript Guidelines and would like some input. The current ideas are on the wiki here:: https://fedoraproject.org/wiki/PackagingDrafts/Javascript
If I don't get some feedback I'll be making some decisions based on the information there in order to have something that's ready for a vote in two weeks.
My current thoughts on positions the draft will take are::
Javascript libraries must be packaged separately from web applications. Web Applications are not allowed to include Javascript Libraries (or plugins to those libraries which have a separate upstream from the web app) but must use the system provided ones.
Javascript libraries must provide an apache conf file that will serve the library from the filesystem to clients from a specific URL. config files for other web servers are optional.
URLs for Javascript libraries should be rooted in /js/
I'm not sure whether to advocate using JsMin or similar or not.
If you don't like some of these ideas, please respond! Nothing's set in stone yet, but without your input, they will get turned into Guidelines.
-Toshio
Just checking -- seems like Apache is going to need to be tweaked to do that in the default conf, else some other RPM may end up owning /var/www/js and having to configure it). Right?
--Michael
Michael DeHaan wrote:
Toshio Kuratomi wrote:
Javascript libraries must provide an apache conf file that will serve the library from the filesystem to clients from a specific URL. config files for other web servers are optional.
URLs for Javascript libraries should be rooted in /js/
Just checking -- seems like Apache is going to need to be tweaked to do that in the default conf, else some other RPM may end up owning /var/www/js and having to configure it). Right?
I think that what I wrote wasn't quite clear. The javascript files would probably live on the filesystem under /usr/share/PkgName
The URL where these libraries could be found would be http://localhost/js/PkgName.
Does that answer your concern?
-Toshio
On Tue April 8 2008, Toshio Kuratomi wrote:
Javascript libraries must provide an apache conf file that will serve the library from the filesystem to clients from a specific URL. config files for other web servers are optional.
When the apache config file is stored below /etc/httpd, any Javascript library has to depend on apache. How about providing the config files somewhere else, so that any user who wants to use it, can symlink it from /etc/httpd or copy it?
Regards, Till
Till Maas wrote:
On Tue April 8 2008, Toshio Kuratomi wrote:
Javascript libraries must provide an apache conf file that will serve the library from the filesystem to clients from a specific URL. config files for other web servers are optional.
When the apache config file is stored below /etc/httpd, any Javascript library has to depend on apache. How about providing the config files somewhere else, so that any user who wants to use it, can symlink it from /etc/httpd or copy it?
That's a good point. I looked at how MochiKit is currently packaged and it does store files in /etc/httpd/conf.d and it does require httpd. Probably not what we want as general policy.
Options: 1) config files should be placed in /etc/SOMETHING A) Users can symlink them if they have apache (Thanks Till)
2) Use %triggers to symlink automatically (triggers can be problematic in the long term)
3) Start using %{_sysconfdir}/httpd/conf.d the same way we use %{_sysconfdir}/bash_completion.d and have all packages that install files there own it.
4) Have filesystem own %{_sysconfdir}/httpd/conf.d or another directory that apache is set to read configs from (this is the approach of xinetd.d)
Comments on why some of these should be preferred?
-Toshio
On Thu, 2008-04-10 at 14:18 -0700, Toshio Kuratomi wrote:
Options:
- config files should be placed in /etc/SOMETHING A) Users can symlink them if they have apache
(Thanks Till)
- Use %triggers to symlink automatically (triggers can be problematic
in the long term)
- Start using %{_sysconfdir}/httpd/conf.d the same way we use
%{_sysconfdir}/bash_completion.d and have all packages that install files there own it.
- Have filesystem own %{_sysconfdir}/httpd/conf.d or another directory
that apache is set to read configs from (this is the approach of xinetd.d)
5) Have /etc/js.d and have a connector package per webserver package that includes /etc/js.d/*.conf.
"TM" == Till Maas opensource@till.name writes:
TM> When the apache config file is stored below /etc/httpd, any TM> Javascript library has to depend on apache.
I'm not really sure why that's a bad thing. Perhaps there's a desire to use a different web server? Do the non-apache web servers we provide also make use of /etc/httpd/conf.d? If not, why haven't we heard more complaints about all of the web applications that install into /usr/share and then map themselves into the URL space with a file in /etc/httpd/conf.d?
- J<
On Thu April 10 2008, Jason L Tibbitts III wrote:
"TM" == Till Maas opensource@till.name writes:
TM> When the apache config file is stored below /etc/httpd, any TM> Javascript library has to depend on apache.
I'm not really sure why that's a bad thing. Perhaps there's a desire to use a different web server? Do the non-apache web servers we
If one wants to use a different web server or no webserver at all, one still has to install apache without gaining anything in most cases, because afaik as soon there is a new version of the config file installed, the /etc/httpd directory won't be removed when the package is removed.
provide also make use of /etc/httpd/conf.d? If not, why haven't we heard more complaints about all of the web applications that install into /usr/share and then map themselves into the URL space with a file in /etc/httpd/conf.d?
I filed a bug against trac a long time ago, because it cannot be installed without apache.
Regards, Till
On Fri, Apr 11, 2008 at 12:18:28AM +0200, Till Maas wrote:
provide also make use of /etc/httpd/conf.d? If not, why haven't we heard more complaints about all of the web applications that install into /usr/share and then map themselves into the URL space with a file in /etc/httpd/conf.d?
I filed a bug against trac a long time ago, because it cannot be installed without apache.
On http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides I describe what I found looking at packages requiring 'webserver', and according to my findings for some package webserver means a server with apache like web server configuration directory and config file (bugzilla, htdig-web, phpMyAdmin, postgresql-pgpoolAdmin, wordtrans-web) in that case the requires may better be httpd.
But I never took time to report on these (and given how reports on packaging issues are treated in fedora, I don't think it is a priority).
-- Pat
Hi.
On 10 Apr 2008 16:59:13 -0500, Jason L Tibbitts III wrote:
I'm not really sure why that's a bad thing. Perhaps there's a desire to use a different web server? Do the non-apache web servers we provide also make use of /etc/httpd/conf.d? If not, why haven't we heard more complaints about all of the web applications that install into /usr/share and then map themselves into the URL space with a file in /etc/httpd/conf.d?
I, for one, use lighttpd for most of my web serving needs, and yes, putting config information only in /etc/httpd is a bit of a bother.
On the other hand, these config files are apache specific, really (lighttpd can do most of the things configured in there, it just needs a different language), so they're not entirely misplaced.
The only alternative I can think of is to ship config files for all web servers we provide, which is a bit unpractical, too.
For fonts we had the same problem : many font packages want to install fontconfig rules, they can not really be interpreted by anything other than fontconfig, but we didn't want to force use of fontconfig whenever a font package is installed.
The solution was to move /etc/fonts/conf.d to the filesystem package, and declare any package could drop files in there, but they would only be interpreted on a system with fontconfig installed