tor 2007-09-27 klockan 21:51 -0400 skrev Kelly: > Nah, just do what they did in openSUSE when the decision was made to move the > Gnome stuff from the /opt folder to the /usr folder - have "compat" packages > that create symlinks to the old locations, so that if the user has scripts > that assume the stuff's still located in /var, they will still work properly. > I'm not entirely sure how well this would work with SELinux, though. A httpd-compat-dir package with a %pre that moves /var/www to /srv/lib/www and makes /var/www a symlink? That might work, sometimes, but it will also break something in some systems and fail to install on others. (Different filesystems, one with, one without ACLs. One big, one small filesystem. Fill up the /srv filesystem so some other service breaks. /var/www is a network mount, /srv is local. I could go on...) This change can not be made transparent. You have to put the change in the release notes and let the admin sort out the mess after an upgrade. That's all you can do. Now can people _please_ discuss: * How to justify this change in the release notes. ("FHS told us to"?) * List of directories in /var that are "wrong". * Suggestions for what /srv structure to propose for the next FHS. I've already given my opinion about /srv, but I'll repeat it: If you necessarily need to impose a structure on it, put that structure only in /srv/lib. Make it /srv/lib/<packagename>. You also need to make sure you follow the FHS or change the FHS regarding what goes in /var and what goes in /srv. To me, the FHS seems rather clear: /var is for files only the app should touch (and perhaps an admin too but preferably not), while /srv is for files which the users or admins need to find, look at and change. One problem is that something like that might change through the lifetime of an application, but you can't start moving things around because of that. /abo -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list