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....