On 20-Jun-2005, Steve Langasek wrote: > On Tue, Jun 21, 2005 at 02:12:56PM +1000, Ben Finney wrote: > > - service-published content goes somewhere under /srv/ > > - /srv/ is site-defined > > - thus shouldn't be clobbered by the package manager > > > That last one's a bit of a blocker, isn't it? We can put stuff in > > /usr/share/PACKAGE/SOMETOKEN/ without worries. But how can we set > > up a web application so it's ready to go, if the right place to > > publish from is not writable by the package manager? > > Yes, there's the rub. I think there's room for moving forward on > this point, I just don't think that editing policy is the place to > start; nor do I think this particular policy bug has anything at all > to do with /srv, because you don't want the files belonging to the > packages themselves to be affected by whatever local policy the site > admin chooses to impose on /srv. Yet some kind of connection needs to be established so that there's a clear default location for how PACKAGE should tell whatever webserver is on the system that there's a new bunch of files to be published. If /srv/FOO/ -> /usr/share/PACKAGE/webapp/ is a level of indirection that's required, are we saying there's another level required to buffer /srv/ from our package system? > > We could pass the question back a level: where should Apache, et > > al, be looking for their web content? How can we tell Apache to > > look under /srv/www/ if that directory is site-defined? > > Telling apache to look there doesn't clobber any contents set up by > the site admin, does it? It's just a configuration default, which > can be changed. Having answered the question of "how does Apache know", I hoped to get closer to answering "how should packages tell $HTTPD". -- \ "If you're not part of the solution, you're part of the | `\ precipitate." -- Steven Wright | _o__) | Ben Finney <ben@benfinney.id.au>
Attachment:
signature.asc
Description: Digital signature