Re: [kde] setting an /opt precedent
On Thu, 2002-01-17 at 15:00, Eray Ozkural (exa) wrote:
>
> On Thursday 17 January 2002 21:44, Jeff Licquia wrote:
> >
> > 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.
When you run, say, "apt-get install kde", you are not given any hints at
that time about exactly what files will be removed, replaced, etc.
(except for the special case of conffiles). The only guide you have
there is the FHS and Debian policy; for example, you can assume with a
fair bit of confidence that installed-from-tarball KDE apps in /usr will
be overwritten, because that's where the FHS says that a vendor can muck
about at will. Similarly, you can assume with confidence that KDE apps
in /usr/local will not be so overwritten.
Users read in the FHS a reassurance that a vendor cannot overwrite
anything the admin sticks in /opt without asking permission. Therefore,
any package that installs files in /opt needs to check that those files
don't exist already and prompt the admin if they do.
In short (as someone else has already joked), all files packages install
to /opt need to be treated as conffiles per the FHS. This would
definitely be an abuse of the conffile system.
> 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.
If you interpret package installation as explicit assent from the
sysadmin to violate policy, then you have just nullified policy in its
entirety. Without a policy, we can do anything we want, including
install KDE to /opt. :-)
Somehow, I doubt that was the intended meaning of the FHS.
> > 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
> dangling ambiguity.
Policy is frozen, as it should be. Take the issue back up after woody
releases.
Reply to: