Re: Joey Hess 2006-05-03 <[🔎] 20060503182315.GC22108@kitenet.net> > > I won't discuss here the goodwill of this change, I just want to > > point out that by now, 110 packages are RC bug candidates because of > > this [2] (422 files installed inder `/usr/lib/cgi-bin'). > > Policy uses a "should" for this, so at most these would be regular > severity bugs, not RC bugs. Also, your list is incomplete since it > doesn't include web servers needing to implement support for the > directory first, which policy or no policy, is a prerequisite for any > package to use this directory. Packages changed to /usr/lib/cgi-lib > before web servers support it could be considered RC buggy, since > they'll no longer *work*. Ack. > The original transition plan for this was broadly, to fix all the web > servers to support /usr/lib/cgi-lib while still supporting > /usr/lib/cgi-bin, then to move the cgi programs, and then presumably to > let the admin do whatever they like with /cgi-bin/ after that. I know I'm late for the party because that was discussed on -policy (though the corresponding policy bug received the last mailing in February 2003 before getting closed), but this sounds very strange to me. Using the path component "cgi-lib" which will even be visible to users of the web server looks like a big chunk of NIH to me. Even worse, it will break existing URLs when CGIs start to move to their location. Additional, why do we expect the admin to put somethin into /usr at all? Why don't we advocate the use of something like /usr/local/lib/cgi-bin? (I'm sure there is a solution that lets both directories map to the same URL path, and if not, we'd probably be better off not changing it at all.) Puzzled, Christoph -- cb@df7cb.de | http://www.df7cb.de/
Attachment:
signature.asc
Description: Digital signature