From: Andrew Kemmy (kemmya at domain free.net.nz)
Date: Tue 10 Sep 2002 - 10:21:29 IST
Disclaimer: contents are not intended to start a distro war, and are
written by a self-confessed Debian newbie.
Summary: "alien -c package.rpm ; dpkg -i package.deb" works sometimes.
<long preamble>
I would appreciate comment from long-term Debian users re the merits of
using alien or other means to convert packages meant for rpm-based
systems where no other option is available. For example VMware, IBM
jdk[1], Oracle etc. These apps are "certified" for RedHat or SuSE, and
I have obtained trial copies e.g. from Oracle technology network. There
is an overhead associated with converting the packages,
but there is also an overhead, particularly in an enterprise
environment, associated with using "SuSE for Oracle, RedHat for foo,
and unmaintained distro SprogLinux for app Y, because it's the only
one the app vendor supports". There is also an overhead with
upgrading operating systems because, for example, the vendor has a
policy of not releasing patches for a version of their OS after a
certain time period (2 years AFAIK for SuSE). One of the reasons I am
considering migrating all my boxen to Debian is that this "distro
upgrade process" promises to be less painful in the long run, but this
will be defeated if I still need to maintain RedHat and SuSE machines
for various apps. There is always UnitedLinux, but it is still
essentially vapourware, and is one of the reasons I am trying to migrate
from SuSE in the first place.
</long preamble>
<long-winded description>
Here is my experience so far with a trial version of VMware
workstation:**
I installed Debian Woody on a test machine, as part of defecting from
the church of SuSE.
The first thing I am evaluating is "can I get all required apps to
run?", and this email started when I got to VMware.
VMware offer .rpm and tgz versions only.
Searching http://packages.debian.org/stable/allpackages.html for
vmware produced nothing, although "non-free" packages are included here.
A quick Google didn't turn up any VMware*.deb packages so I decided to
try making my own:
Install kernel headers, gcc
#alien -d VMware_version_number.rpm
#dpkg -i vmware_version_number.deb
so far so good, but on running vmware-config.pl
I got an error message "cannot find
/etc/vmware/locations, aborting"
To overcome this and other errors I did :
#cp /mnt/other_machine/etc/vmware/locations /etc/vmware
#cp /mnt/other_machine/etc/init.d/vmware /etc/init.d
#chmod +x /etc/init.d/vmware and change "#!/bin/sh" to "#!/bin/bash"
(even though /bin/sh was installed the script wouldn't run, although I
think it was simply the permissions)
Then I was able to run vmware-config.pl, reconfigure networking etc..
For some reason the vmware-wizard program had to be run seperately,
from a shell, as the main program interface reported that it "wasn't
installed"..
Apart from all that it all worked quite well, but my install method
was thoroughly inelegant, given that the main motivation for using
Debian is it's packaging system.
Alien has a -c option which can attempt to convert
and execute scripts as part of the installation process, but this
option comes with a "use with caution" message.
Well, it is a test system, so...
I tried -c option to alien, and got a deb package, but
the only "postinstall" script was installer.sh - the vmware installer. I
uninstalled the original .deb package and rm -rf'd related non-empty
directories and installed the "alien -c" modified one. There were no
strange errors this time, and I was able to run "vmware-config.pl" as
per an rpm-based install.
/etc/vmware/locations and /etc/init.d/vmware were installed
automagically.
The stop and start scripts for the vmware services were installed and
functioned correctly.
The only apparant issue is that the resulting vmware binary is not
SUID, which it needs to be to run the program as a normal user. The
good ol' "vmware wizard" is accessible from the program interface.
Update : however, upon trying to actually install virtual machines,
having set /usr/bin/vmware and /usr/bin/vmware-ping SUID, I got some
odd errors.
"strace vmware /home/andrew/redhat.cfg -x" showed "arithmetic errors"
etc,
which were solved by upgrading to 2.4.18 and recompiling the VMware
modules.
</long-winded description>
I guess the main issue is that the production of a VMware .deb has
limited use, as I would need authority from VMware to redistribute
it, and that this is an issue that comes up frequently with
binary-only, non-redistributable packages. At least I know that I can
install and run this app relatively painlessly within the Debian
packaging system.
I note that Storm Linux, which I know nada about, is based on the
Debian packaging system, and that their "standard edition" came with a
VMware trial package.
I also appreciate that there is a big difference between VMware and
Oracle, in terms of cost, place in an infrastructure, and probably the
complexities of their installer programs. In Oracle's case the app
chooses the operating system it likes, as not much else will be running
on such a machine, whereas with an end-user system there may be more
tradeoffs possible between maintainability of the OS and the apps it
supports.
I'd just like to get feedback on the approaches folks have to these
sort of issues.
[1]
http://www.debian.org/doc/manuals/debian-java-faq/ch5.html#s-installer
has some comments on IBM jdk, but there are caveats about licensing
issues. It seems in general that the approach is to create a
meta-package called "commercial_app_xyz_installer.deb" and to use this
as the interface to installing the app itself ?
[2]As a complete aside, the process of writing and modifying this email
caused me to try to improve upon what I had already achieved. Thus
there is a "Zen effect" where a documented problem becomes something
to research, and then a solveable problem, resulting in an email that
sits in one's drafts folder well beyond it's send-by date. Although
some would argue that the send-by date for this email isn't attainable
on 32-bit platforms.
I need to get out more.
Regards,
Andrew
-- Unknown Error in .SIS (.sig Information Services) . Please notify your Administrator, including the time, date, and anything you may have done to cause this error.
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:18:45 GMT