Re: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux