Re: Packaging MB-System, some questions
>> -- 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?
> 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 "."
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