I'm commenting a bit between the paragraphs to sharpen my mind :)
On Wed, Nov 04, 2009 at 08:09:18PM +0100, Stefano Zacchiroli wrote:
> What I was aiming to is a kind of document root which is under full
> control of the package manager; hence where the sysadm cannot touch
> anything by hand. That's actually the only way to have a meaningful
> package-based namespace.
I agree. The files installed by the package manager must be seperated
from user/admin files.
> The property I'd like is that if a package drops static files there
> under a dir like package/, then those files automagically appear (in the
> default vhost) as http://localhost/package/.
That would mean dropping all files in whatever dir is configured (in all
available web servers) as DocRoot.
> Now, written this way, it looks harder to implement, because it is a
> kind of overlay over a default docroot (unless we assume the default
> docroot is read-only for the sysadm, which doesn't look reasonable).
Right, either the admin can (and will) write to the DocRoot (which was
meant to be reserved for the package manager), or we need two DocRoots
configured which I don't think is possible with common web servers.
> I see two solution to this:
>
> - either the final URL is something like
> http://localhost/debian/package/ (replace "debian" with whatever
> prefix you like) and have some other per-web-server mechanism take
> care of adding an Alias/link/whatever from "debian" to that new static
> doc root
Like all packages drop their files in /var/lib/www/package and some
default package (or the web server itself) drops a symlink
/var/www/debian -> /var/lib/www ?
This would again lead to at least one file name in the sysadmin's space
that he/she can't use which is what we try to avoid in the first place.
> - or we add some kind of postinst-time registration mechanism (with all
> the usual drawbacks) that check that new static doc root and register
> every (new) dir there as Alias for the installed web servers.
That is basically what happens today in many cases, except that the
files aren't dropped in one location but rather in /var/cache/$package
or similar. The package's postinst registers the new files/dirs with the
web servers (usually just apache2 and/or lighttpd).
> Assuming that web servers can register themselves to the mechanism,
> that would also solve the problem that webapp maintainers not
> necessarily have the knowledge of the syntax of all available web
> servers
You mean like a trigger that is dealt with by any web server installed?
> Any other idea?
Actually, I don't see a way to implement that (but then I'm probably not
the best code writer). It would be really nice if the web servers could
somehow register themselves for this but I think in the end this is
really what webapps-common was aimed at, isn't it? Except the
self-registering of web servers webapps-common could solve this all. A
package build-depends on it and gets provided with necessary
post{inst,rm} lines to register with known web servers. Considering that
there are that many web servers in the archive, it should be managable
for webapps-common maintainers to keep up2date with those.
So, after all I think we need some manpower in webapps-common and we
have a solution. Or not?
> Many thanks for sharpening the analysis, Jan.
You're welcome, although I prefer to be called Hauke. I'm a
middle-name-user ;)
> PS please keep the -webapps Cc:, I believe it is truly relevant to
> this thread
Ack, sorry for dropping it before.
Hauke
Attachment:
signature.asc
Description: Digital signature