On Sun, 15 May 2011 18:00:50 +0200, Lennart Poettering <[email protected]> wrote: > I already have trouble enough understanding why we currently have both > /usr/local and /opt. Both appear to be places for 3rd party software, > but use different layouts. I am tempted to say that we should just get > rid of /usr/local. Well... they're quite similar.... :)
Actually I was very impressed how you "got through" with the introduction of /run ;-) ... and it could be possible to convince people in dropping /opt,.. but I doubt that you'll get them to drop /*/local. It's just used in too many places (e.g. default PREFIX for thousands of open source projects.) Have you had a look at the proposal for a "definition" on how /usr, /usr/local and /opt could be related/defined? > That said, /opt appears like a pretty badly though out > solution. i.e. any package you install there which need drop in files > in some system dirs (i.e. dbus service, pk policy and so on), also needs > to add something to /etc or /usr, so I really wonder what the point of > the separation here. This is a good point,... but don't forget that by far not all programs (and especially "3rd party binary packages" make use of dbus/pk/ck/etc. And sysadmins tend to prefer keeping these things separated from the normal system. e.g. if I get proprietary Mathematica, or Dell Management software ... I really don't want them to put any stuff in /usr or /usr/local (where their stuff could get accidentally in my PATH)... but I'm quite happy to "isolate" it in /opt > For example the XDG basedir spec ignores /opt completely, but includes > /usr/local in the default search paths. Personally I don't like adding /usr/local in the search paths (mostly for security reasons). Cheers, Chris. _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
