>>"Brian" == Brian White <[EMAIL PROTECTED]> writes:
Brian> Once it becomes official policy, then I can get them to make the
Brian> necessary changes. And once the webservers begin to change over,
Brian> then I can get the packages to change.
Perhaps things have changed in the last 3 years, and they
shall understand that post the /usr/doc issue policy has become more
conservative?
Brian> <webroot>/cgi-bin should default to "~www-data/cgi-bin".
Brian> However, existing implementations should not be automatically
Brian> changed so as not to break anything. Once all packages follow
Brian> the new policy, then they can do semi-automatic changes to the
Brian> /cgi-bin setting.
I suppose you mean <webroot>/cgi-lib should default to
"~www-data/cgi-bin". I am with you so far. The only thing that has
changed so far is that the public interface may be changed to
<webroot>/cgi-lib, but nothing changes behind the scenes, and there
is no reduction in name space pollution.
Brian> The reason no webserver must do a behind-the-scenes changes is
Brian> that the webmasters of some existing implementations will have
Brian> started inserting CGIs in the existing place and we should be
Brian> careful not to break that.
Quite so. Local cgi-scripts should _always_ be accessible
under <webroot>/cgi-lib.
Brian> Once done, installed scripts will be available via both
Brian> "/cgi-bin/script" and "/cgi-lib/script". The packages then
Brian> change all of their webspace references to be
Brian> "/cgi-lib/script". However, both before they make that change
Brian> and after it is done, there is no interruption of service.
Yes. But the scripts still live in ~www-data/cgi-bin, right?
If not, I missed when you are going to have packages move the scripts
out.
Brian> Once all the packages have changed over, then webmasters can
Brian> start using the "/cgi-bin/" alias for what it was intended:
Brian> local CGI programs.
I see two problems. The name space pollution has not been
reduced -- since all scripts live in the same dir on disk; my
cgi-file could be overwritten by a debian package. All we have done
is created two names for the same underlying directory; but not given
the sysadmin a private place to keep his files that is safe.
Hmm. I forgot what the pther problem I thought I had with this.
Brian> If you can see a problem with this, please let me know. It's
Brian> been presented before and everybody seemed happy with it.
Perhaps I am being dense, in which case, please point out my
fallacy to me.
manoj
--
Date: 28 Feb 90 02:03:37 GMT From: [EMAIL PROTECTED] (Randal
Schwartz) $_ = <<END; s/../pack('C',hex($&))/ge; print;
4a75737420616e6f74686572205065726c206861636b65722c END
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
