Re: [kde] setting an /opt precedent
On Thu, 2002-01-17 at 16:26, Eray Ozkural (exa) wrote:
> No, I would lean to interpreting package installation as explicit assent to
> overwrite files contained in the package, and removal to remove files.
That's not good enough, because you often don't know what files a
package contains when you "apt-get install" it.
Suppose, for example, that I added /var/spool/mail/exa to, oh, cupsys.
Do I automatically gain your permission to overwrite your mail spool,
just because you use cupsys and typed "apt-get upgrade"?
One can only assume that packages have permission from the sysadmin to
overwrite or remove files in a manner consistent with Debian policy
(which includes the FHS). Any more lax assumption about the sysadmin's
intent inevitably leads to an eradication of all policy if applied
consistently.
(This applies only to official Debian packages. As has been pointed
out, you're certainly free to do your own packages and put things
wherever you want.)
> I see. However, it is not very clear whether that phrase has any meaning. If
> it's going to be practically impossible for distributions to install files in
> /opt, why is it allowed in the first place? If it's going to be possible for
> a local system administrator to form his own packages under various
> /opt/<package> then why isn't a location in /usr/local adapted for this
> purpose? Who is going to maintain the packages under an /opt/<package>?
> System software or the local administrator? That paragraph doesn't seem to be
> consistent at all, and it isn't a good division of responsibility.
Generally, I interpret the FHS this way:
/usr -> package management system
/usr/local -> source tarball installs
/opt -> Windows-style binary installs w/ a foreign installer.
Thus, /opt isn't a distro issue at all; it's there to accomodate people
like Loki. Of course, that's just my interpretation, and my preference
in setting up my own systems.
One possible scenario where a Debian package may install into /opt would
be a hypothetical "opt-manager". This package could iterate through
/opt/* and create symlinks from /opt/*/bin into /opt/bin, possibly with
some GUI that allowed the admin to turn packages in /opt on and off,
install new packages into /opt, whatever. Since all of this would be
done via interaction with the sysadmin, it's all allowed under the FHS.
It could even be done automatically, as long as the package included
debconfage to alert the sysadmin to the fact and offer to disable the
automatic stuff.
Reply to: