Wednesday, December 14, 2005

Cleaning Up the File Installation Mess

Who knew Christmas shopping would be useful?

The other morning I played hooky from work to go Christmas shopping. Don't worry, I took annual leave.

I took a break from my arduous task by getting a coffee at the local Borders. Before I got that, though, I looked around for something to read and found the Jan/06 issue of Linux Journal. I intended to put it back when I left, but it was so useful that I decided to shell out the $5.25 to buy it.

Which brings us to the current topic, an article by Marcel Gangé on cleaning up your $HOME (or other) directory after you've installed a program from a tarball.

So what's the problem? If you're new to Linux, you may have only installed programs from RPM or Debian .deb files, then you might not have encountered a tarball. Heck, if you use yum or apt-get you might never have seen an .rpm or .deb file at all, even though they are there.

Simply put, a tarball is collection of files that will install a program for you on your system. Unfortunately, usually the files are the source code for the program, plus some "hints" (a file called configure and another called makefile, or maybe Imakefile) on how the files are to be compiled. The tarball is a compressed archive file, usually with a name like fineprogram.tar.gz or fineprogram.tgz, the "gz" indicating that everything is compressed with the gzip program.

Now installing from source is a chancy proposition — my current success rate is maybe 90%, but some programs just won't install on my system, probably because I'm missing some key libraries (that's why we have yum and apt-get, to handle these dependencies).

For now, though, let's assume that you've got the program compiled, and even installed (more about that later). You delete the source code directory as a bunch of junk you'll never need again, and run the program happily.

Until one day, you find that the program doesn't really do exactly what you want it to do, and you decide to delete it from your system and replace it by a newer program.

A small problem: The program may have left traces of itself in /usr/bin, /usr/lib, /etc, /usr/share, and maybe /opt, just out of a general sense of perversity. Where are all those files?

Well, if the program was nicely written, you could go back to your source directory and run "make uninstall". This looks for a set of commands in the makefile which remove all of the installed program components.

Unfortunately, you deleted the makefile along with the rest of the source, remember?

Oops.

Now, this post won't tell you how to clean up that mess, but it will tell you one way of preventing the mess from happening.

The secret is a program which Gangé's article talks about extensively: CheckInstall. Basically, the program (available as a tarball, RPM, Slackware, or DEB file) keeps track of where all of the files a tarball installs are, and makes it easy to delete them if you want to. It does this by creating a RPM, DEB, or Slackware Binary file. You install this just like you would a binary file you get from your distributer, and you can delete it the same way.

How does it work? I'm just going to discuss how it works under Fedora, so I'll create an RPM file. I think it works pretty much the same way for Debian and Slackware files, but that's for you to test out.

For an explicit example, let's assume that I want to install the FVWM window manager from source.

That last link should get you a file called fvwm-2.4.19.tar.gz, a tarball with the FVWM source code. Compiling this code is actually fairly easy. You just open up an terminal window, and execute the following commands:

$ tar tvzf fvwm-2.4.19.tar.gz
$ cd fvwm-2.4.19
$ ./configure
$ make
$ sudo make install
$ cd ..
$ rm -fr fvwm-2.4.19

What's all that do? Let's go through it line by line:

  1. $ tar tvzf fvwm-2.4.19.tar.gz uncompresses the tarball. This creates a directory named fvwm-2.4.19 and puts all the files you need into it.
  2. $ cd fvwm-2.4.19 goes into that directory.
  3. $ ./configure runs a program which searches your machine and decides if you have all the libraries you need to compile and run fvwm. If you do, it will create a makefile which has the locations of all the files you need to run the program, plus appropriate compiler flags.
  4. $ make executes the makefile. Typically this will take minutes to hours, as all the components of your system are compiled. If it's successful, then
  5. $ sudo make install will put all of the program bits where they belong. You need the sudo if you want to install the program in /usr or /usr/local, or someplace else that's owned by the superuser.
  6. $ cd .. returns you to the directory above fvwm-2.4.19.
  7. $ rm -fr fvwm-2.4.19 deletes the source code.

What does CheckInstall do? It gets rid of the "make install" step. Basically, you run the following commands:

$ tar tvzf fvwm-2.4.19.tar.gz
$ cd fvwm-2.4.19
$ ./configure
$ make
$ sudo "/usr/local/sbin/checkinstall"
$ sudo rpm -i /usr/src/redhat/RPMS/i386/fvwm-2.4.19-1.i386.rpm
$ cd ..
$ rm -fr fvwm-2.4.19

The process is pretty self-explanatory. You can give the default answers to all of the questions, tell the code to create an RPM file, and it will tell you that it has created an RPM file in the location /usr/src/redhat/RPMS/i386/fvwm-2.4.19-1.i386.rpm or wherever. The exact name and location depends on the installation. (All these "su" and "sudo"s will require the appropriate passwords, by the way.)

So what's the big deal? The RPM file installation process knows where all the files belonging to fvwm-2.4.19 went on install. Thus, if you later decide you don't want to use FVWM as your window manager,

sudo rpm -e fvwm removes the program from your system, along with all of the auxiliary files it installed.

Now, a word of warning: this is not a real RPM file. "Real" RPM files have dependency information in them. What's that? Well, say that FVWM depends upon a library called "libfoo". If for some reason I remove the "libfoo" RPM from the system, a "real" RPM installation would tell me that this is going to break FVWM. However, here the RPM isn't connected to "libfoo" so far as your RPM system knows, so it won't warn you. Also, you probably can't pass this RPM off to a friend with any hope of him getting it to run on his system: he's better off trying to compile the code himself.

However, it does make file installation and cleanup a lot neater, and so is extremely usefull.

And well worth the $5.25 for the magazine.

0 comments: