Hamish wrote: >> -- GMT paths: >> >> Debian's GMT package does a funny thing with the GMT package, it installs >> the 140 binary programs into /usr/lib/gmt/bin instead of directly into >> /usr/bin. ... >> I'm guessing this is to keep /usr/bin/ from being overloaded, but is it >> still desirable and needed to do that? MB-System makes heavy use of the >> GMT programs, and is designed in a similar way with 74 of its own command >> line do-one-thing-well programs and scripts. ... >> Better ideas? Should I file a wish to move GMT binaries back into /usr/bin?
Andreas: > The usual reason to move a set of binaries from /usr/bin to > /usr/lib/<pkg>/bin is to avoid name space conflicts. Unfortunately when > having such a number of binaries most probably one or to with short or > generic names have the same name in common with some totally inrelated > binary from some other package in Debian. With a little test-loop for the GMT binaries I don't see any conflicts: for FILE in `dpkg -L gmt | grep /usr/lib/gmt/bin/` ; do apt-file search /usr/bin/`basename "$FILE"` apt-file search /usr/sbin/`basename "$FILE"` echo -n "." done But I'm not sure if that gets things like alternatives symlinks or not though. Most of the GMT bin names are pretty specialized; less than 10 seem like variations on generic words which someone else might possibly use one day. (psxy, x_list, ...) for MB-System the binaries all start with mb_* or mbm_* [macros] so less likely to have a namespace conflict. >> My current solution (which I'm not really happy with either) is >> to add a file to /etc/profile.d/ called gmt_path.sh containing >> PATH="$PATH:/usr/lib/gmt/bin"; export PATH ... > Your solution to set the PATH accordingly might be a reasonable addition > to the wrapper script. is it Standards legal/nice to make that happen for another package? > Hope this helps thanks, Hamish -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
