Changing the location a module is loaded from without changing the default path
 

I'm trying to get my Epson SP7600 printer working correctly, it will not print from gimp with "custom" print sizes (24"x16"), giving a failure in ghostscript, using the default Lenny gutenprint and ghostscript releases. I've downloaded and installed the latest gutenprint version (5.2.6) but it appears that the 5.0 version is what gimp is using...
x@y:~$ whereis gutenprint
gutenprint: /usr/lib/gutenprint /usr/lib64/gutenprint /usr/local/lib/gutenprint /usr/share/gutenprint
The version I want to access is in the 3rd path, /usr/local/lib/gutenprint, the others are the 5.0 version. I'd prefer not having to change the path variable and I don't want to have to rename any of the paths as it will complicate upgrades, as I understand it there's a means to tell the system to find the gutenprint executable in a specific place and that seems the least "dangerous" method to me. Could someone guide me as to how this can be done? If the gutenprint change doesn't solve the issue I'll also be upgrading ghostscript and will need to do the same for it, if neither upgrade fixes the problem I'll be able to report the issue without having to hear the usual "are you using the latest versions?" question.

Maybe I'm missing something, but why can't you just symlink the file to a link where you want it to be?

HTH,

HaroldWho

I believe I could do this, but whilst searching the web earlier today on a related issue I stumbled upon a mechanism that seemed simpler to use and maintain and unfortunately I failed to make a note of it. It wasn't "alias" but it was something that appeared to operate similarly, associating a specific path to a command/program, in that particular case it was something issued against ghostscript (gs) telling the OS what when gs was called /x/y/z/ was the path that should be used for the executable. I fear that once I start creating symbolic links things will grow complex and without in-depth notes an upgrade will break something that will take me forever to fix, my last foray into Linux I managed to make a mess of things by installing software outside of the package manager which resulted in having to rebuild much of my work upon upgrade, I'm trying to find the simplest mechanism to use and maintain and do undo/redo once Sid (or whatever) becomes the stable release. Worse comes to worst I'll symlink and pray that I can understand my habitually cryptic notes when it comes time to change something but I'd much prefer something simpler that is tied to the program itself rather than being dependent on modifications to paths and the mechanism I saw but failed to note appeared to be capable of surviving major upgrades with little or no intervention to accommodate these one-off installs. After many years experience in IT I have learned that the k.i.s.s. principle should be the holy grail of programmers and tweakers, and it seems I've seen some allusions to a mechanism that can do what I want in a very simple way.