binary executables not in standard path

Bug #49120 reported by Schplurtz le déboulonné on 2006-06-09
Affects Status Importance Assigned to Milestone
gmt (Ubuntu)

Bug Description


install gmt and you will find all the binary files (except "GMT") in

Previous version of GMT (3.4) used to put things in /usr/bin.

As this path is generally not in users' $PATH, gmt is no more useable.
Old scripts (even simple ones) that use gmt simply completely break


Jérémie Corbier (jcorbier) wrote :

According to the source gmt does not follow the file hierarchy standard. Thus the maintainer made some packaging choices (and hacks :)) and one of these choices was to keep all the executables in /usr/lib/gmt/bin except for GMT. GMT must be used as an interface to the other tools (using "GMT toolname" syntax).

Changed in gmt:
status: Unconfirmed → Rejected
Download full text (4.6 KiB)

Good evening,

I hope you realise, that this breaks not only old scripts but also
long years of habits, and you do force users to do things your way.

If things were installed in /usr/bin as they've always been, users
can have their work done either way : 'GMT command' or 'command'

I may add that if you take a look at the example on the GMT site, you
will see that they do not use "GMT tralala" syntax. for example :

Now, the fact that GMT is not FHS compliant is a bad news for a package
maintainer, but, IHMO should not have any consequences for users.

I made a patch (directly in the 'debian' directory) that solves this
problem. it justs move files from /usr/lib/gmt/bin to /usr/bin .
To be very compatible and cautious, I kept /usr/lib/gmt/bin , but it
is now a symlink to /usr/bin.
I had to add a prerm and a postinst because, dpkg won't allow a
directory to suddenly become a symlink.

I did some testing :
1) Run the examples contained in the gmt-examples
package. They were all successful. So it runs with the files in

2) package management
Upgrade the package from the actual version, to the patched version : no problem.
installed more than once the patched packaged without deinstalling : no problem
purge the package : no problem
install again : no problem
run lintian : two more diagnostic than with the non patched package :
 W: gmt: binary-without-manpage gshhs
 W: gmt: binary-without-manpage gshhs_dp

 This is simply because the files are now in /usr/bin and lintian
 can catch them.

So I really hope that you will give my patch a try.

Christophe Martin.

*** ./rules.orig Sun Jun 11 02:52:51 2006
--- ./rules Sun Jun 11 02:52:51 2006
*** 70,75 ****

   # GMT wrapper does not help in /usr/lib/gmt/bin (not in path by default)
! # So: Move it to /usr/bin
! mv $(DESTDIR)/usr/lib/gmt/bin/GMT $(DESTDIR)/usr/bin/

   # Move the manpages directory to the right place...
--- 70,94 ----

   # GMT wrapper does not help in /usr/lib/gmt/bin (not in path by default)
! # Other commands feel better also if installed in /usr/bin, so
! # while we are at it, we move everything to /usr/bin and provide a
! # symlink from /usr/lib/gmt/bin to /usr/bin, so that GMT is still happy.
! # In fact we will create the symlink in postinst because dpkg won't
! # accept to change a directory to a symlink.
! #
! # We also change the GMT wrapper so that it execs /usr/bin/toto instead
! # of /usr/lib/gmt/bin/toto. The latter would work since we install a
! # symlink, but the former is more efficient as it does not read the
! # symlink that, precisely, goes back to /usr/bin
! #
! # We could think, that since we patch the GMT wrapper, the symlink is
! # not really needed any more.
! # But I prefer to keep it, just in case some thing somewhere uses
! # /usr/lib/gmt as a base and assumes that the binary should then be
! # at /usr/lib/gmt/bin. Call this fear, uncertainty, or compatibility or
! # caution.
! # OK, after all these deep thoughts, let's do it :
! sed -e 's,$$/usr/lib/gmt/bin,/usr/bin,' $(DESTDIR)/usr/lib/gmt/bin/GMT >$(DESTDIR)/usr/bin/GMT && chmod 755...


It solves the problem by moving the files during the build.
The resulting package was tested. all examples in gmt-examples work

installing, upgrading, reinstalling, purgeing and installing again were all successful on my machine.

It's probably worth giving it a try.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers