On Mon, 2009-04-20 at 22:02 +0300, Juha Tuomala wrote: > It sounds like there should first be a specification and > then we should implement it. That would be nice, but unfortunately > there isn't. This industry has plenty of examples from de-facto > implementations until they are formally standardized. There is a specification, which is that the site admin gets to decide how that path is used. That is it. Period. > > > /srv/ is hands off, undefined layout to be managed by the local admin, > > period. We can't make any assumptions about what is in there, nor how > > it is being used. > > If shell looks under /srv in addition to /etc/profile.d it would allow > local admins use it. Look where though? We can't pre-create directories, nor can we assume any layout as that may have adverse effects based on how the admin is using /srv/. > If they choose not to, they should do nothing. Such > improvement could even be switched off in some /etc/sysconfig file easily. > I don't see how it would intrude their autonomous area if it wont > force them into anything. > > The whole point of /srv is to have your server's role data in single > location for obvious reasons. I can imagine that people running Fedora > as server would appreciate such option due more frequent upgrades. > /srv exists as a place admins can put things without worry of the operating system interfering. Once you start interfering, /srv/ looses it's usefulness, and admins will start making /data or /web or other such things again. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
