[Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?)
mattdm at mattdm.org
Mon Oct 23 18:44:07 UTC 2006
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
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
Matthew Miller mattdm at mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
More information about the Fedora-packaging