On Thu, 2006-01-19 at 07:58 +1100, Matthew Palmer wrote: > On Wed, Jan 18, 2006 at 04:40:12PM +0200, Ivars Strazdins wrote: > > Sam Morris wrote: > > > it should really live in /usr/lib/<package name>. If the use of /opt > > > is hard coded into the package then, well, that sucks. :) > > > > It is hard coded into management decision to which I really have no > > access whatsoever. > > > > > see <http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9> for > > > details. > > > > Thanks, I also thought I should go this way. > > But what to do with $PATH ?:( > > Wrappers in /usr/bin. If there is a Management Decree that No Package File > Will Be Outside /opt, then you're screwed unless you can mandate the use of > /bin/bash, and ship a modified /etc/profile. Not at all. By default, PAM will read /etc/environment and include those variables in every session, regardless of which shell it uses. Still, forcibly modifying the default path in an installation script is Bad and Wrong. > Time to re-read "How To Win Friends And Influence People", and go to work on > the management twonks making your life difficult. There is that... There are complete indices of the files installed by packages in the Debian archive, so when creating a new package it's possible to check for and avoid collisions with existing ones. If a package is never going to be part of the Debian archive (perhaps because it's not freely redistributable), there's no such mechanism. In this case it seems to me to be reasonable to install most of its files under /opt/$vendor. I don't know what I would do about including its binaries in the path though. Ben. -- Ben Hutchings In a hierarchy, every employee tends to rise to his level of incompetence.
Attachment:
signature.asc
Description: This is a digitally signed message part