Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 09:26:49PM +0200, Eray Ozkural (exa) wrote:
>
> As explained in section 3.8, it is obvious. Local system administrator, as I
> have written, manages the contents of the following directories.
> /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man
>
> A distribution therefore cannot touch the content of these subdirs, however
> it can install software in a package directory
> /opt/<package>
> under which the files pertaining to <package> are maintained. FHS explicity
> allows this.
>
> In any case, since distribution cannot install anything in the above
> mentioned subdirs, the front end files are to be placed in those directories
> controlled by the distribution such as /usr/bin.
what? how can the distribution place files, such as /opt/bin/kde, in a
directory it is _forbidden_ to touch?
secondly, /opt/<package> may be installed by me, since i went to kde.com
and got my own tarball. now if i apt-get install kde, either a) my
self-rolled kde gets wiped out or b) i do not get the official kde.
if the distribution is forbade from touching /opt/bin, and /opt/bin is
part of $PATH, how is kde supposed to work w/o change to the default
environmental variables? (ie: w/o adding /opt/kde/bin to $PATH)
the use of alternatives? what does that gain over the current ``stay out
of /opt'' methodology?
i see _no_ gains by using /opt.
if any part of opt is for local sysadmin use (/opt/bin), then the whole
of /opt should be reserved for local sysadmin use.
-john
Reply to: