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
