Friday, April 29, 2005

Articles: Making packager-friendly software (part 2)

More or less a month ago, the first part of my Making packager-friendly software article was published at ONLamp.com. I was happy to receive comments from several people saying that they liked it (sorry if I haven't replied to you yet; I've been very busy during the past few weeks).

Now it's the time for the second (and last) part, which has just seen the light. It deals with recursive dependencies, handling of configuration files, unprivileged builds, the make utility, build infrastructure oddities and some details about code portability. I hope you enjoy it and try to make your projects a bit more packager-friendly in the future! ;-)

Monday, April 11, 2005

Modifying the environment from scripts

Two days ago, a friend of mine was trying to modify the environment (the CLASSPATH) from within a shell script. Her intention was to run the script and then start working with Java on the same shell were the script was run. This didn't work. In order to explain why, I'm going to review the three different ways to run scripts and how they are related to the current environment.

Let's create a sample file, named foo.sh and stored in the home directory. Its purpose will be to modify a variable and create a function:

FOO_VAR=hello; export FOO_VAR
foo_func() {
echo "Hello, world!"
}

Now, before running it, ensure that the environment is clean (i.e., that the variable is empty and that the function is undefined. To make things easier, just open a new terminal.

It's time to run the script. The first attempt will be to execute it using the shell interpreter explicitly:

$ sh ~/foo.sh
$ echo ${FOO_VAR}
$ foo_func
ksh: foo_func: not found
$

Oops! It didn't work. Why? I hear. Well. When you run the script this way, you are launching a shell sub-process in which the script is executed. Therefore, when the shell exits — which happens upon file's EOF — the modifications to the environment are lost.

Let's try it in a different way, this time using a shell bang. Edit the foo.sh script and add #!/bin/sh as the very first line (there can't be any spaces before this). Then, give it execute permissions and try again:

$ vi ~/foo.sh
... add #!/bin/sh at the beginning...
$ chmod +x ~/foo.sh
$ ~/foo.sh
$ echo ${FOO_VAR}
$ foo_func
ksh: foo_func: not found
$

What? It didn't work either. This case is equivalent to the previous one; the only difference is that the OS creates the sub-shell for us: it sees the magic shell bang ("#!", or "#! /" in some old OSes) at the beginning of the file and uses the program name given there to run the script.

The last possibility — and only solution to the problem — is to run the script in the same shell process as we are working, so it will modify the current environment. Think of it as if you were manually typing the contents of the file in the window you are working on.

How is this done? Just call the program with a single dot before its name, separated by an space. This magic keyword tells the shell to "source" the given file:

$ . ~/foo.sh
$ echo ${FOO_VAR}
hello
$ foo_func
Hello, world!
It worked. Hope it's clear now! PS: The export keyword I used in the sample file is used to tell the shell to propagate the given shell variables to further sub-shells, not parent ones. If you don't use it, then the variable is private to the current instance of the interpreter and won't be visible from anywhere else.

Sunday, April 03, 2005

Increasing RAM to 1GB

Since I bought my latest workstation (summer of 2003), I'd been running with 512MB of RAM. During all this time, I was "angry" seeing how the system used swap space when it was somewhat loaded — e.g., GNOME running with a bunch of applications in the background (Epiphany, Evolution, aMule, Gaim, Beep Media Player...) and compiling some stuff. You know, when the system uses the swap, the performance (or at least, the responsiveness) decreases dramatically. For some reason, I kept blaming the OS for using the swap, rather than thinking that my hardware was not enough.

Yesterday, taking a look to a list of prices, I saw a 512MB DIMM (Kingston, 333MHz DDR, CL2.5) for only 42€, a considerable fall in its price since the last time I checked. I was a bit dubious to buy it, but at last I did it.

Now I don't regret that decision at all. The system feels much smoother than before. Just to test it, I've been building KDE in the background while doing daily stuff in GNOME (with all the applications mentioned above loaded), and it hasn't touched the swap for anything. Great.

If you are in a similar situation and don't know what to do, just go for the update!

Saturday, April 02, 2005

pkgsrc: Linux distributions

As you may already know, pkgsrc is a packaging system that works on many different operating systems — not just NetBSD. Linux is included among these. pkgsrc will work fine on most Linux distributions, but IMHO, there are some that are more pkgsrc-friendlier than others (basically because their original packaging system may be limited).

First of all, there is (or was, since the homepage seems to be dead) Bluewall GNU/Linux, which claimed to be a distribution including pkgsrc as its default packaging system. I never got to try it, though.

Secondly, we have Slackware, a distribution that has been around for a very long time (hmm, I remember when I used 3.4, which taught me a lot about Linux...). It is known that its packaging system is limited; maybe not in the number of available applications, but surely in its infrastructure. This is a good choice because you can easily clear the base system of any clutter and proceed to install anything else from pkgsrc. Martti Kuparinen wrote a tutorial about how to do that.

Then we have Arch Linux, a rather new distribution. I recently tested it in its 0.7 version and seems to be fairly good. Minimalistic, fast, and BSD-like (specially in its boot scripts). Just as in Slackware, it's easy to remove anything "extra" from the default installation and use pkgsrc to handle everything else. The little advantage is that you'll have a better packaging system to handle those packages that can't be replaced by pkgsrc.

At last, there is a hopefully ongoing project by Jeremy C. Reed to create a 100804e680kgsrc-based Linux distribution. I'd love to see that become true, but we are not there yet (I'd say it's just a matter of time ;-). You can check a little FAQ he wrote for more information.

Of course, pkgsrc can be used on any other Linux distribution. Personally, I've used it on Debian and Fedora Core. The choice is up to you.

Friday, April 01, 2005

Articles: Making packager-friendlier software (part 1)

During the past summer, I started writing an article which details a set of serious problems I usually find when packaging third party utilities. These problems are very annoying, but usually not difficult to fix. They are generally caused because the original software authors are not packagers in most cases, so they are not aware of the things described here. Summarizing: the article analyzes these issues and gives some advice to solve them, in the aim that software developers make easier to package applications.

Why it took so long to get published? Well, I forgot about it until January, when I took it again. At that time, I finished some pending sections, polished some details and, at last, prepared it for its release. Finally, yesterday's evening, it went live on ONLamp.com (this is my first contribution to the site). You can read more in the article itself, Making packager-friendlier software (part 1).