On Fri, Jun 5, 2015 at 11:31 AM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Fri, Jun 05, 2015 at 01:31:10PM +0000, John Florian wrote: >> Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE, >> but to my knowledge the FHS has never ratified anything like that. The >> FHS seems to take a rather vague stance on /opt overall IMHO. > > This is actually specifically addressed in FHS 3.0, released, actually, > _just this week_. See > > http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30 > > and specifically > > http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html > > and the provider list: > > http://www.lanana.org/lsbreg/providers/providers.txt > > which includes Fedora. (Credit to Tom and Toshio for working on this.) Given the profound discrepancies between the FHS 3 and everything that systemd touches, I'm afraid it's become a confusing guideline for Fedora work. In particular, the insistence in sytemd of putting mountable medie under "/run", and of migrating system-specific conffigurations from "/etc" to "/run are at direct variance with even that most recent FHS. So it's not going to be a complete or reliable guideline. Tools like RT, puppet, and chef that may be open source, but require extensive internal modules and libraries that are incompatible with other system components are prime examples of tools that benefit from segregation from the rest of the environment. I've taken a shot at resolving the ruby gem dependencies of chef, and some Java integration for puppet, and perl module librares for RT. It's a nightmare to resolve the dependency hell: they're much safer to manage separately. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
