Alan,
I'm a little slow sometimes, so correct me if I'm wrong. :-) The FHS states that "add-on application software packages" such as "foo" are installed in /opt/foo/bin/foo with a symbolic link from /opt/bin/foo. Configuration would be in /etc/opt and variable files would be in /var/opt. I don't see how /opt applications are treated differently than /usr/bin applications, except they are segregated from the base OS. Therefore NFS exporting /opt add-on applications should work fine as long as /etc/opt and /var/opt are configured correctly. The FHS states that no software packages are to be installed under the /usr hierarchy; therefore, my interpretation is that add-on applications are *required* to be installed in /opt, and not /usr nor /usr/local. Is this not the case? Back to my original inquiry: How does one resolve /opt conflicts between similar packages being released from separate sources? What does one do if there are two or more java, cc, etc? /opt/java/, /opt/vendor1/java/, /opt/vendor2/java/, and /opt/vendorN/java/ or /opt/java/, /opt/java/vendor1/, /opt/java/vendor2/, and /opt/java/vendorN/ Does the later require a name registry? What is the rule for who gets the primary /opt/<package>/? http://www.pathname.com/fhs/2.0/fhs-3.8.html Thanks, PS: I don't see a FHS email distribution list on http://www.pathname.com/fhs/ Is there one? George (gk4) Alan Cox <[EMAIL PROTECTED]> on 02/16/2000 03:46:55 PM To: George Kraft/Austin/[EMAIL PROTECTED] cc: [EMAIL PROTECTED] (Alan Cox), [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FHS section 3.8: /opt/<package>/ > Not use /opt ? Isn't that what the LSB spec and FHS V2.0 is specifying? The FHS and LSB don't specify you have to use /opt. They allow /opt to exist but there are good techmnical reasons for not doing so - think about NFS sharing of /usr but not /var and the fact thin client is important (The FHS is probably the right place for that discussion) The naming issue applies regardless
