Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
On Tue, 14 Sep 1999, Steve Lamb wrote:
> Tuesday, September 14, 1999, 2:45:56 PM, Jakob wrote:
> > On Wed, 15 Sep 1999, Federico Di Gregorio wrote:
>
> >> IMHO, /usr is what we (Debian) control, /usr/local is what I (the
> >> sysadmin) control, /opt is where third-party package builders (e.g.,
> >> Corel, KDE, Cygnus, etc...) control.
>
> > I don't think that there is a more succint way to put it. Bravo!
>
> /usr is what we control, /usr/local is what I control, /usr/opt is where
> third-party package builders control.
>
> Your assignment is to now tell me why his is valid and mine is not. He
> didn't address my point that /opt does not deserve a top-level directory.
Let's try this:
In general, software that is going to wind up in /opt (or /usr/opt, as you
seem to prefer) is going to be binary only, restrictively licensed
software. FHS states that /usr must be sharable over a network - e.g. if I
have several i386 machines running Debian potato, only one of them need
have /usr, and the others can mount /usr via NFS. This is fine for
everything in /usr, put their by Debian, since we know that there will be
no restrictions on those programs. As for programs in /usr/local, the site
admin will be putting those there, generally from source, and licensing
should not be an issue there, either. However, the license for application
Foo may state that it may NOT be accessed over the network, and you only
have a license to run it on computer Bar. If it is installed in /usr/local
or /usr/opt, you are implicitly violating the license, since computer Baz
has the same /usr tree as Bar. But, when opt is at /opt, it is not shared
and such hassles can be avoided (of course, it can be even more easily
avoided by staying away from non-free software, but then that would
eliminate any need for /opt).
--
Jakob 'sparky' Kaivo - jkaivo@ndn.net - http://www.ndn.net/
"As time goes on, my signature gets shorter and shorter..." - me
Reply to: