[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers



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

Attachment: signature.asc
Description: Digital signature


Reply to: