Re: [kde] setting an /opt precedent
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 17 January 2002 23:11, Jeff Licquia wrote:
> 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.
Yes, sort of like what kernel packages do. It would be very annoying if KDE
packages did that for instance. Certainly not acceptable.
> 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.
:) That would be a far-fetched abuse.
> > 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. :-)
No, I would lean to interpreting package installation as explicit assent to
overwrite files contained in the package, and removal to remove files.
> Somehow, I doubt that was the intended meaning of the FHS.
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.
> Policy is frozen, as it should be. Take the issue back up after woody
Ah, sure. It's frozen already. I must append another line to the never
finishing TODO list. :)
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-----