I can't lie to you about your chances, but you have my sympathies. – Ash to Ripley in Alien

Debian packages have a reputation for reliability, but Alien [1] is a notable exception. The problem has nothing to do with its code. Rather, the problem is that its purpose – to convert packages to other formats – is so dependent on the purpose and quality of the packages it works with that the success rate is mostly unpredictable. Despite its limitations, Alien remains a popular package. The dream of compatibility across package formats is simply too tantalizing to abandon.

Alien was first written before the turn of the millennium, when the balance of power between package managers was more equal. Back then, developer Joey Hess thought it made sense to give Debian a means of converting .rpm packages to .deb format.

These days, with popularity tilted toward Debian derivatives like Ubuntu and Linux Mint, users of .rpm-based distributions like Fedora are more likely to find Alien useful, even though its Debian origins remain obvious. In recent years, most Debian-derived distributions include Alien in their repositories, although you will still have to hunt it down specifically in Fedora and other .rpm-based distributions.

Alien is most reliably used on packages with either few or self-contained dependencies. For example, fonts, clipart, and audio collections work well because they generally require no dependencies.

When a converted package requires dependencies that other applications require, however, problems may arise, because different distributions do not always place files in the same directory. These days, even Debian derivatives might not use the same file locations, although the odds are usually in your favor.

When the original package does assume different locations, it either won't install or won't work. If the converted package is one that the system requires to work, such as init or libc, you might even find your system unbootable.

True, recent versions of Alien include options to allow you to edit the converted package. However, making use of these options requires knowledge of where core files are located on your system and involves either altering the script or creating symbolic links for the package to use. You might get a certain satisfaction from hacking the package so it works, but you might find the manual conversion more effort than your interest in a package merits.

If you are not equipped to fine-tune a package, the comprehensive man page suggests a sensible rule to follow: "If you can't remove a package without breaking your system, don't try to replace it with an alien version."

Supported Format Conversions

You can tell which distribution technology Alien was first written for because, even now, the command defaults to creating a Debian package. To begin, login as root, so you can be sure of access to all dependencies, and enter:

alien PACKAGE

The output will be a Debian package in the same directory as the original package and one version number higher. You can add additional files to convert in a space-separated list, and you do not need to specify an output file.

Alien's options include -d or --to-deb, but they seem to exist for the sake of completeness more than anything else. If you do have problems converting a package to Debian, the cause is most likely the lack of one of the basic commands listed in the man page, such as gcc, debhelper, or make. On a non-Debian system, you might need to download the alien-extra package [2].

Alien also converts to and from the Solaris .pkg format with -p or --to-pkg and Stampede packages with --to-slp (and no other option), and from tar files (.tgz) with -t or --to-tgz. However, tar files only work if they contain binary files in a standard Linux directory tree; otherwise, Alien will produce the requested output file, but it won't work. Even worse, if the tar file contains source code, the converted package will simply install the source code in the root directory, leaving you to delete it.

Other than .deb, .rpm is the most common format for conversion. It is chosen by the addition of either the -r or --to-rpm option. In my experience, it tends to be the most reliable non-Debian format to use, perhaps because it is the most in demand and more work has been done on it.

As an offshoot of its .rpm support, Alien also includes support for packages created by the Linux Standard Base (LSB) [3]. The LSB project attempts to standardize the filesystem hierarchy on distributions. Its packages are a subset of the .rpm format, usually prefixed by lsb-.

In theory, conversion to or from LSB format should be more reliable than any other format, because the prefix minimizes the potential conflicts in dependencies. At times, the practice matches the theory. Too often, though, the practice falls short of the theory. Not all distributions fully support the LSB (even those involved in the project), and the packages that are LSB compatible are in a definite minority. Still, if you are lucky enough to find LSB packages you want to convert, they seem the likeliest format to be trouble free.

Face to Face with Alien

If you are very sure about the package you are converting, you can add the -i or --install option to the basic command to install the result as soon as it is created and then delete the package.

By default, the output package will have a version number one higher than the original package, but if the version number is important to you, you can add -k or --keep-version to leave it unchanged. You can also use --version=VERSION to specify a version or --bump=NUMBER to increase the version by more than one. My personal preference is to leave the version number unchanged, which makes the original package easier to find again.

However, even if you are confident about the package, Alien is probably best run verbosely so you can troubleshoot. It includes two verbose modes: -v or --verbose and the even more chatty --veryverbose, either of which can help you figure how to create a workable package (Figure 1).

Figure 1: Running Alien with one of its verbose options lets you see exactly what the command is doing and helps you to troubleshoot.

Alternatively, if you hope to create a Debian package, you can use -T or --test as a dry run (Figure 2). Taking this extra step can help avoid many of the problems that a misapplication of Alien can cause.

Figure 2: Using the -T or --test option results in a dry run, so you can see what will happen if you run Alien for real.

If the converted project requires tweaking, you have several options. If you have built Alien from source and patched it, you can see a record of the patches in /var/lib/alien. When creating a Debian package, you can specify the particular patch to use with --patch=PATCH. You also have the options of --nopatch or --anypatch, either of which can be used in the hope that a different version of Alien will give you different results.

Another way to tweak is to use --fixperms to correct the permissions in the package being converted. If you study Alien's verbose output, you will notice that much of the conversion process involves altering permissions, so this can be a useful option. You need to be careful, though, because the options can either clean up confused or mixed permissions or remove required ones – which is exactly why you should avoid running this command without examining the package contents first.

The same is also true for -c or --scripts. Both of these options try to convert the scripts so they run on your system. However, given the potential problems, in some cases you may be better off manually editing paths in the package.

With any format, you might also want to copy the original package to another directory and then use -g or --generate (Figure 3). Instead of creating a package, these options create staging directories from which you view and/or manually edit the files in the package in a text editor, just as you would when building a package from scratch. The command displays the name of the directory as output. Just remember to back up the package if you are using the option only for informational purposes.

Figure 3: Using the -g option creates a staging directory that you can use to modify the package contents and from which you can then build a package.

When you have finished manipulating the original package's files, you can then rebuild it as a package for your system. Given enough expertise, that is probably the most reliable way to use Alien, although it may be beyond your knowledge without a bit of study beforehand.

Knowing When to Quit

Many users quickly become impatient with Alien's imperfections, and, to some extent, they are justified. Alien deals with so many moving targets that it is unlikely ever to become completely reliable – nor can anything as simple as adding a graphical interface take the place of expert knowledge of filesystem hierarchies or package building [4].

Users with less expertise – that is, the majority of us – often have to decide how far to pursue the use of Alien on a particular package. On one hand, Alien can be a quick solution for installing a package and can keep all the packages on a system under the control of the package manager, making them easier to find and remember.

On the other hand, when trouble arises, sooner or later you need to make a choice. Alien users can either continue to invest time in fine-tuning, hoping eventually to produce an installable package (and learning valuable system information as a by-product), or else cut their losses of time and effort and install the package some other way – perhaps in a virtual machine running a distribution that can handle the package you hope to use or by compiling from source. Alien can seem almost magical when it works, but, in some cases, you may eventually be better off with another installation solution.

The Author

Bruce Byfield is a computer journalist and a freelance writer and editor specializing in free and open source software. In addition to his writing projects, he is also a fan of parrots, heavy exercise, British folk-rock, science fiction and 19th century novels. In his spare time, Bruce writes about Northwest coast art. You can read more of his work at http://brucebyfield.wordpress.com.