[Leaplist] Single tree application installation

[Steve Litt]

Bruce pointed us to an article advocating software installation by copying a 
directory tree to your hard disk. I've been doing that for years, and after 
reading the article redoubled my efforts to single-tree install.

As many pointed out in the ensuing thread, one-tree installs are problematic 
because of libraries. Which is one of the three reasons I program in an 
interpreter (Perl, Python, Ruby, Scheme) whenever possible. Under those 
circumstances, the interpreter must deal with libraries, but the distro has 
probably already taken care of that.

At the last GoLUG meeting, some dissatisfaction with Linux was voiced because 
all too often, if you want to upgrade for example your LyX, you have to 
upgrade for example your Qt4, and then you have to upgrade this and that and 
the other, maybe even libc.

This problem is greatly decreased if the app is written in an interpreter, and 
interpreters change much slower than libraries, so it's likely an identical 
app could be installed on almost all distros with versions any time in this 
century, especially if you don't use bleeding edge features and additions to 
your interpreter.

Sometimes for performance or hardware linkage reasons you can't program in an 
interpreter, but when you can, I think interpreters are the way to go. I'll 
give reasons for that assertion later.

My latest app, and it's about 80% done, is a reminder system that flashes 
prominent reminders of upcoming events on my screen. I researched and tried 
several existing reminder/calender apps, but they didn't work exactly how I 
wanted, so I wrote my own. 

After the reminder from the article pointed to by Bruce, I've paid particular 
attention to encapsulation inside a tree. The entry point to all the system's 
functionality is a single shellscript that sets and exports all necessary 
environment variables. The first thing the shellscript does is check that 
it's being run in the application directory:

export appdir=$(pwd)
if test -e $appdir/genrem_append.pl; then
	true
else
	echo
	echo ==================================================================
	echo $2 $appdir/genrem_append.pl is missing.
	echo $2 You probably started this program in the wrong directory.
	echo $2 You must start it from the Steve Litt Reminder System directory.
	echo ==================================================================
	echo
	exit 1
fi

Therefore, the user doesn't have to define the application directory inside a 
configuration -- he just has to start it from the correct directory, and that 
directory is then used as the application root. Anyone's capable of starting 
an app from a specific directory, and a user with a lick of sense can create 
a 3 liner on-path shellscript to cd to that directory and run the program.

After that, the top level script sets a few more environment variables to be 
used by called shellscripts and perl programs, and then calls the proper 
shellscript or perl program to do the work. The environment variables mean 
called programs don't have to define directories matching the top level one.

In other words, except for the optional on-path 3 liner shellscript to invoke 
my program, EVERYTHING is contained in the program's tree. That's not quite 
true -- there's an area for temporary data, and on a multiuser system that 
must be off the user's home directory or some other per-user directory, but 
that's pretty easy to do, possibly in an automated method (use whoami to 
deduce the user, and create approot/home/myuid to be chmod 600 for 
myuid.myuid. Directories for permanent data would have to be outside of 
appdir in order that an upgrade wouldn't destroy them.

I promised to give the reasons for my preferring interpreters:

1) It's usually easier to do it with an interpreter, giving you more time to 
get it stable and secure.

2) You can't walk off the end of an array or issue an errant pointer from most 
interpreters, greatly reducing security problems. Of course, the interpreter 
itself could have a security bug, but the guys creating Perl, Python and Ruby 
are a heck of a lot smarter and test a heck of a lot better than me, so their 
security bugs are much less than mine would be using C, C++, and a framework.

3) Using an interpreter, your application doesn't need direct communication 
with libraries, but instead accesses them through the interperter, so a 
single tree installation becomes practical.

And once again, writing an app in an interpreter makes it much more likely you 
can install it on any Linux box young or old without dependency problems, 
especially if you don't use too many extensions for the interpreter.

So Bruce, thanks very much for posting that article. It reminded me of things 
I was starting to forget.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.