On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote:
> > Obviously Fedora-packaged apps can expect whatever Fedora
layout Fedora
> > provides.
> Why is that obvious?
Because it's unreasonable to forbid an entity to rely on its own
actions? The FHS wrote its specification in the context of an app
Yeah, but Fedora is not forbidden from relying on its _own_ actions, but
rather from relying on _my_ actions. Although it's perfectly reasonable for
Fedora to provide a default, it shouldn't/can't rely on me or you keeping
that default, because, as Axel points out, there's many perfectly good ways
for arranging this directory depending on system usage.
installed on a foreign system, not in the context of a distro which
controls the whole system
This is exactly the point of /srv. The distro does not control the whole
system -- the sysadmin does. However, the distro should be constructed to
help the sysadmin as much as possible.
The FHS basically writes app authors must write apps so app users
can
configure whatever /srv/ layout they want. It says no entity can expect
another entity to provide any particular /srv/ layout.
But in the context of a distribution :
— we are providing a /srv/ layout for ourselves (acting in-stead of
users, which is what distributions are supposed to do)
— users are still free to reconfigure apps with whatever policy they
prefer if they don't like the Fedora one.
I agree with you so far.
However, the phrasing "Fedora-packaged apps can expect whatever Fedora
layout" seems to assume that add-on web packages which don't have a good
mechanism for being reconfigured other than rebuilding would be free to rely
on some layout for /srv. Instead, they should be fixed so they don't have
to.
Additionally, there should be no risk of any local data in /srv being
overwritten on package upgrade. Package-managed files shouldn't be in there.
(See the cvsweb and munin rpms in extras, for example.) This is pretty
straightforward -- user-edited data and RPM-handled files don't mix well.
(The conf file .rpmnew/.rpmsave kludge isn't viable here.)
I don't see how the document could be read otherwise. The
alternative
would be to forbid *any* pre-configuration for *any* service the FHS
puts in /srv/, which is plain ridiculous (should apps ignore conf files
settings and embark in automagical /srv/ exploration heuristics too?
that's another absolutist reading)
It works pretty well with Apache via the /etc/httpd/conf.d/welcome.conf
mechanism....
--
Matthew Miller mattdm(a)mattdm.org <
http://mattdm.org/>
Boston University Linux ------> <
http://linux.bu.edu/>