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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
