Hello Torsten, > The reason to put GMT binaries into a directory other than /usr/bin is > the name space pollution that would result. Currently, GMT comes with > 119 commands and only 15 of them are easily identified as belonging to > GMT (by having a gmt prefix). The institute where I used to work uses > Seismic Unix as well and it already has two utilities with a name that > is used in GMT as well: pscontour and psimage. It is quite frustrating > having to debug a script that uses either GMT or Seismic Unix depending > on what comes first on $PATH. Right, but AFAIK, there is no "seismic unix" debian package, so the pollution occurs only at your old site, and because of a non debian product... At my site, people use seismic unix but also Caraibes, which is not something that one likes to reconfigure. Caraibes relies on GMT for a few operations. When you move GMT binaries, you break Caraibes.
Caraibes is not a debian package, Seismic unix is not a debian package. One wins, the other looses. And I'm sure there exists many sites around the world with their own tools. If you have GMT in /usr/lib/gmt/bin people will use PATH=/usr/lib/gmt/bin:$PATH for compatibility reasons. They simply won't rewrite their scripts, nor will they start to use "GMT toto" syntax. Then you install SU, People will start to use PATH=/SUHOME/bin:$PATH And you'll have headeach trying to debug SU or GMT scripts again, because of PATH problems. This PATH problem cannot be solved by moving GMT binaries. I keep thinking that, continuity and compatibility are the key words > > Therefore the Debian package will stay that way. It should be documented > though, which is why I won't close this bug right now. I you really won't change the package, then the warning is a good thing. Christophe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
