The Answer Gang

By Jim Dennis, Karl-Heinz Herrmann, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!

---

Generic installer locations

From Jay R. Ashworth

Answered By: Thomas Adam

I have a project, sitting here on the desk in front of me, for a menu program that I need to decide on an implementation language for.

The target environments are SCO OS5 and quite some different number of Linux distros; the possible languages are Python and Perl.

While I don't especially care if the buyer can see the code, what I do care about is not putting the installer into either dependency hell or conflict hell, while still having the pieces I need to do the work.

This seems like a reasonably common problem; any suggestions on how to approach it?

[Thomas] Graphical, console or both?

[Jay] I suppose that was pertinent, yes; it's a menu program; text, but full screen.

[Thomas] Who cares what language you'll write it in? ncurses is ported to Solaris, as is slang. You can probably even use "dialog". All of these libaries have bindings to lots of languages. As for the "benefit" pffft. Just use what comes naturally to you.

[Jay] I apologize; I thought I'd made my specific point clear on the first pass:

This program, when done, sold and shipped, needs to be able to install and run reliably on all target platforms without conflicting with, or, really, depending on, whatever language runtimes might or might not already be there. I don't object to depending on what's there, or brilliant installers, or any of that stuff, but on SCO, I'm likely to have an ancient Perl and no Python at all...

[Thomas] Ok. So as long as you ensure you compile against a modern glibc, you should be fine. But what you cannot expect is something near perfect. If a potential target doesn't have XYZ installed then they should ensure so. Clearly versions of dependencies <= compiled_version will be OK, and you can test for that.

[Jay] and on Linux, you never know what will be there -- or what you might break if you have library/module conflicts.

[Thomas] Indeed.

[Jay] So, again, going back to Fred Brooks' System Program Product concept (you know, the thing that takes 9 times as long as a simple hack? , what is the best approach to this?

[Thomas] Well, if you do have an antiquated version of XYZ where you know that in most cases the software on the target machines might well be newer, it should be a safe [1] approach to assume that the code you have is "backwards compatible" with what you produced -- i.e. it won't be using the newer features possibily present.

[1] In theory, great. In practice, err.....

Skip various snide comments -- Thomas Adam

[Jay] I propose to deploy as a commercial product a program written in a language which expects an installed interpreter, with a system-wide directory of modules.

If that infrastructure exists, I don't object to using it (assuming that everything's the right version). But if it's not there, it's not my place to install it -- the client isn't buying a-complete-perl-install, and I don't want to be responsible for that, anyway.

[Thomas] OK. Well, most distributions tend to put things like that in standard locations (/usr/share/$foo || /usr/lib/$foo)/ Often, these paths will have various environment variables defined depending on the platform you're installing it to, so that is definitely something to check. Of course that depends on the language it is written in.

[Jay] I don't have 6 years and 40 machines.

[Thomas] I know what you mean, time is short. What I really meant by this is getting a Solaris machine, a linux machine, an HP-UX machine, whatever and seeing what the differences are to compensate. How else will you know otherwise?

[Jay] Because that doesn't take into account what might have already been done adminstratively to the machine.

[Thomas] Ok.. well, what I would do in that case is rely on the fact that there are known locations for modules or what have you for the said language. Most distributions follow the LSB or FSH to an extent such that all packaged versions of the languages should adhere to the agreed paths. So you can make a default assumption of the likely place they'll be, and if so, use the intended language to test for the infrastructure of where everthing is (env vars, internal vars to the language, etc).

If the administrator has been messing around with standard locations, then he/she should have enough synapses left to know what to do. As a default though, you could always install in: /usr/local/ and export LD_LIBRARY_PATH as necessary, and let the administrator know that if they know of a better place to put them, to ensure that it is done.

---

This page edited and maintained by the Editors of Linux Gazette
HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

---