The utility of alien (Re: Aptitude wants to remove OpenOffice.org)
Manon Metten wrote:
> Still two question remains in my mind. First: What good is Alien for?
It is the best attempt yet to automatically convert an rpm file to a
deb file. But just because it is the best automated process available
available does not mean that the deb produced is good. As the old
saying goes, "You can't make a silk purse out of a pig's ear." It may
be a purse but it would still be a pigs ear and will never be silk.
So much of the result depends upon the quality of the original rpm
file. If the original rpm is good then the resulting deb will
probably be acceptable. If the original rpm is poor then the result
is similarly poor.
For example if the rpm packages files for /usr/local/bin/foo then the
resulting deb will also contain the same /usr/local/bin/foo file.
This is in direct violation of Debian Policy. A standard Debian
package would never be allowed to do that as /usr/local is reserved
for the local admin.
For example an rpm might make assumptions about user and group
ownership. For example on Debian apache runs as www-data but on Red
Hat IIRC it runs as the apache user.
For example if the rpm package contains a daemon it will usually
contain an /etc/init.d/foo script to start the daemon. But system
startup is often system dependent. What numbers will it use to order
itself in the startup sequence? (e.g. 'ls /etc/rc2.d/'.) On Debian
systems there is no difference between run levels 2, 3, 4, 5. On Red
Hat systems there is a difference and each runlevel has a defined
behavior. If the daemon were to only set itself up to start in
runlevel 5 then it would not start automatically on Debian. RH init.d
scripts usually need to use chkconfig to configure the startup
symlinks in the rc?.d directories but on Debian update-rc.d is used.
RH init.d scripts usually source /etc/init.d/functions but that file
does not exist on Debian. RH init.d scripts usually source files from
/etc/sysconfig/ but that directory hiearchy does not exist on Debian.
The init.d scripts are not capable of cross platform use directly and
will probably need to be rewritten. So for a daemon there are all
kinds of reasons why alien might not be able to do an automated
conversion and that it might need a person to make the port manually
with some human intelligence.
Both rpms and debs may run scripts at post installation time to
configure the files. But because of system differences these might be
quite different. Because of these potential problems by default alien
does not convert scripts from rpm to deb. This can mean that the deb
won't get the same configuration that was in the rpm.
The naming of rpm files and the naming of deb files are often
different. For example at one time ncurses4 was not available in
Debian. I converted it directly using alien and the result was a deb
called ncurses4. But in Debian the name should have been libncurse4.
Later when this became available as a native deb package with the
proper name I found myself without a clean automated upgrade path. No
amount of 'apt-get dist-upgrade' or 'install' or 'upgrade' would get
me from one to the other. I had hundreds of machines that I needed to
script a custom upgrade script that checked to see if this package was
installed and remove it first. But of course it was more complicated
than that but that is another story.
> Alien enables the conversion of binary packages provided in Red Hat
> rpm, Stampede slp, Slackware tgz, and Solaris pkg file formats into a
> Debian deb package. If you want to use a package from another Linux
> distribution than the one you have installed on your system, you can
> use alien to convert it to your preferred package format and install
> it, alien also supports LSB packages."
>
> (http://www.debian.org/doc/manuals/reference/ch-package.en.html)
I think that it gets such a small mention so that hopefully people
don't notice it. :-)
The wording is probably in need of improvement. You *can* do it. But
*should* you? That all depends. If there is a good native Debian
package then I would say almost always use the Debian package. But if
not and you really want the files from the rpm then alien can be of
help and use to make them installable as a deb package.
> How could I have known the danger of using Alien?
I think only by being aware of the differences between the systems.
Understanding what rpms are and contain and how they interact with the
system and the same for debs. Alien tries to map from one to the
other and it does a fair job of it. Reading and participating in
discussion on debian-user is a good way to learn these things. :-)
> Second: What to do if no debian package exists at all? Eg: suppose Adobe
> Acrobat would only be available as an .rpm package (and not as a tarball
> like now). What should I do in such a case?
Since Adobe is available as a deb natively let's use a different
package such as 'xv' as one real example. The license is not
completely free. The 'xv' program is free for non-commercial use but
not commercially. It also contains other restrictions. It does not
meet the DFSG therefore it cannot be included in Debian. There cannot
legally be an official Debian packages for xv although some people
have contributed unofficial ones. The functionality of xv has been
completely replaced by other packages and so this is not one that many
people would miss today but at one time xv was quite popular. But
someone might want it out of nostalgia so let's use it as an example.
There are many rpms for xv. Searching on http://www.rpmfind.net you
might find an xv-3.10a rpm built for SuSE 10.1. This is a perfect
example of an rpm that could be converted and installed with alien.
It is not a daemon. It does not have any scripts. It only contains
files. There are no special permissions or other special needs. The
original rpm is of good quality and well behaved. This is a perfect
candidate for alien to convert automatically. Let's do it.
$ fakeroot alien -k --to-deb xv-3.10a-1091.i586.rpm
xv_3.10a-1091_i386.deb generated
Worked fine. What is in there? The same files that were in the rpm
package. In particular files will be installed in /usr/X11R6/bin
which on Debian is a symlink to /usr/bin and so this will work but
will not be in the "right place" for Debian[1]. The documentation
will be installed in /usr/share/doc/packages/xv/ instead of in above
it in /usr/share/doc/xv. It is not a showstopper and everything will
work fine but it is not in the "right place" for Debian. Some people
would fail to find the docs after installation because they are not
where they are expected to be located. But the program will still run
okay so for some people this is good enough. Those people are hard to
convince that problems even exist. They don't know what they don't
know. For them alien works great! But for me I want *everything* to
work along with upgrades. Therefore I am cautious about the use of it.
Note that just because I used xv as an example does not mean that I
recommend it. On the contrary I recommend against it. The license is
most certainly non-free with plenty of restrictions. Instead I use
ImageMagick and xloadimage, xview, feh, etc. All of those are free
software and work great. But xv made a good example as one that I
have run across before that people wanted on Debian that was not
otherwise available as a deb package.
So in summary for some packages alien can do a passably good job. For
others, not so good. There is also an option for alien to do half of
the conversion and then stop leaving a human to finish things up.
This is a good helper mode that can bootstrap things along more
quickly. Although at that point if I am involved I would probably
just do a full native port for it.
HTH,
Bob
[1] In Sarge /usr/X11R6/bin was a real directory and installation of
this deb would cause an upgrade from Sarge to Etch to fail since the
upgrade would be unable to clear all of the files from it before
converting it to a symlink. So it is not a great place for it but
works on the surface. See this reference for more information.
http://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#s-xorg
Reply to: