Re: [kde] setting an /opt precedent
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 17 January 2002 21:44, Jeff Licquia wrote:
> That is not what the text of the FHS says. There is no limitation
> mentioned that states that the admin cannot install software outside of
> /opt/bin, etc. And, wherever in /opt the admin decides to install
> software, packages "should not modify or delete software installed by
> the local system administrator without the assent of the local system
> administrator." Period.
> We cannot currently ensure that a package installing to /opt cannot
> overwrite admin-installed software there.
Thanks for the explanation. That's a quite vague statement. How does one
modify or delete software ... without the assent of the local system
administrator? After all, it is the local system administrator who runs the
packaging commands. Theoretically, there isn't much difference between
running dpkg or rm. Moreover, if you consider the context of the above quote:
Distributions may install software in /opt, but should not modify or
delete software installed by the local system administrator without the
assent of the local system administrator.
It would seem to imply for instance if I have installed a package foo in
/opt/foo, the system must not overwrite files in /opt/foo without my
knowledge. However, this paragraph doesn't seem to be very consistent to me
since distributions can be said to provide the "assent of local system
administrator" in any case... It's a matter of interpretation.
> As you yourself have mentioned, if you don't like the plain text of the
> FHS as presented, take it up with them.
No, I don't like it.
However, I am not very good at writing concise statements fitting for FHS,
and I am not yet a developer either. Could you please take up this small task
and add an interpretation of the above statement to the Debian Policy? I
think it should be in the form of "We cannot install any files in /opt, since
Debian has no way of tracking what local software system administrator may
have installed." I think such a clarification is needed since there is a
I think your message wraps up the discussion. Thanks again.
Eray Ozkural (exa) <email@example.com>
Comp. Sci. Dept., Bilkent University, Ankara
GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----