hi, On Wed, May 03, 2006 at 03:02:49PM +0200, Alexis Sukrieh wrote: > W: bugzilla: file-in-usr-lib-cgi-bin usr/lib/cgi-bin/bugzilla/ > N: > N: Packages shipping web server CGI files should install them in > N: /usr/lib/cgi-lib, not in /usr/lib/cgi-bin. This is done to avoid > N: conflicts with the cgi-bin script alias, which is reserved for the > N: local use of webmasters. Web servers should include /cgi-lib/ as a > N: standard ScriptAlias pointing to that directory.
this is a surprising change. guess that's what i get for not being
subscribed to -policy :)
first, i don't really see what the merit is of moving files from
/usr/lib/cgi-bin to /usr/lib/cgi-lib.
second, AFAIK, /usr/lib is still the domain of dpkg/debian and not the
"local use of webmasters", so why should we have to move the files?
it seems to me that the policy *at least* should instead say:
- if it is really for the local admin's use, web servers should have
/cgi-bin point at /usr/local/lib/cgi-bin or somesuch
- /cgi-lib points at /usr/lib/cgi-bin
but i'm still grappling to understand the rationale behind why this
is a desirable thing. if the desire is to provide a way for the
local admin and packages to be able to share a script aliased directory,
i would argue this is entirely the wrong way about it. i'd be happy to
elaborate further.
> I think that we should document somewhere how to handle this
> migration. Just changing the path /usr/lib/cgi-bin to /usr/lib/cgi-lib
> in our debian/rules isn't enough, we have at least to warn the user
> that he has to make sure that his webserver provides a Script Aliasing
> feature from cgi-lib/ to cgi-bin/.
i would argue that /usr/lib/cgi-foo is an outdated approach anyway, and
that most applications ought to be scriptaliasing /package/cgi-bin
or /cgi-bin/package to somewhere under /usr/lib/package (this would in
fact be another use for the non-existant libexec dir...). but that's
just my $0.02.
in any case, this will also require updating of configuration files and
for some systems a lot of grep+sed will need to be done if the internal
systems reference something with cgi-bin in the url. it'll also break
a lot of bookmarks, though that should really be the least of our
concerns.
a note to the debian-policy folks: you may or may not be aware that
we've done a significant amount of work regarding drafting a comprehensive
and sensible policy for web servers and web applications. i don' think
it's quite ready for submission (i think the unspoken assumption is that
we'd submit it for etch+1, and after webapps-common was introduced into
the archive), but your feedback on what we've come up with so far would
be very much appreciated:
http://webapps-common.alioth.debian.org/draft/html/
for any of you who are going to be at debconf, we're hosting
a BoF session on all this too.
sean
--
signature.asc
Description: Digital signature
