Thanks for your response, Charles! On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote: > As a maintainer of a web application, I share your worries. I never had any > user request to make it work out of the box with alternative web servers, so I > guess that my users have nothing to gain and everything to lose in a change. I > strongly suggest that the transition is experimented on a few volunteer > packages before increasing the workload of many persons – users and > developers.
I think this is a bit black or white. Users (ar rather admins) gain the possibility to easily guess where a package is to be found. No looking for /usr/share/package/html or something, just assume it's /usr/share/www/package. And they don't lose everything, they just need to read the chapter (yet to be written, of course) in the release notes about web applications being moved; additionally NEWS.Debian should be provided by any relevant package and so on. Also, I said, a proper migration path has still to be figured out. The question for now is: do we want this change at all and -- if so -- shall I file bugs against the web servers. I'd suggest severity wishlist for the start. > For new packages, grouping everything in /usr/share/www sounds like a good > idea. The alias name, « vendor », I find a bit disturbing because we do not > sell anything. But picking the name will be the priviledge of the Do-o-crat > who > will lead the transition, I presume. Well, I find 'vendor' a bit confusing as well but I'm not a native english speaker and I don't have better ideas. Shoot if you have any. Something like 'debian', 'webapps', 'applications' seem way to generic for this. > Still, having /usr/share/www as a document root does not prevent complex > packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/, > /var/tmp, /var/run and /etc. Maybe you can double-check how many web servers > are able to cope with that before starting to invest a lot of time. Otherwise, > since shipping configuration files in /etc/webserver/conf.d will still be > necessary for these packages to work, there will little benefit in moving > files > to /usr/share/www. And there isn't even a way we could (or want to) solve this. Applications of many sorts have to deal with FHS, webapps are nothing special in that matter. We can't allow an admin to fiddle aroung with files in /usr/share, nor can we just pump all webapps into /var as this will break (or at least bloat) many backup strategies and cause other problems. Until now I thought simple symlinks work with every webserver and thus didn't see a problem for that. It's the application that sometimes needs patching to deal with its being splattered around. Am I wrong here? Hauke
signature.asc
Description: Digital signature