[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: