From: Rick Moen (rick at domain linuxmafia.com)
Date: Tue 10 Sep 2002 - 20:50:34 IST
Quoting Andrew Kemmy (kemmya at domain free.net.nz):
> 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.
It often works OK. Where you find that it hasn't, you can "apt-get
remove packagename", and you're no worse off. (Obviously, alien doesn't
do much to make packages compliant with Debian Policy.)
You can alternatively elect to pull apart the RPM using rpm2cpio and put
its pieces as locally-installed software under /usr/local . Obviously,
for good or bad, this results in the package-tracking system knowing
nothing about it. (Thus, if the package depends on particular other
packages that _are_ under dpkg/apt control, you'll want to put the
latter on status "hold" to retain them categorically.) Also, it would
be a lot of work for complex packages: You'd probably use the technique
only for simple ones (which have fewer pieces to tuck away).
Last, that technique _can_ require that you understand a fair bit about
how the package's pieces work, where they should go, etc. There could
be obstacles if some fool has compiled in absolute paths, and so on.
> 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.
If you care about vendor support, you should stick scrupulously to
vendor platform requirements. In the case of Oracle, you're basically
going to devote a machine to it anyway, so using a one-off instance of a
distribution that isn't your preference that's on the vendor's certified
list (particular releases of SuSE and Red Hat, in Oracle's case) isn't
much _more_ of an inconvenience.
Oracle is an example of a vendor that has both extremely twitchy OS /
version dependencies (I have really bad memories of glibc problems), but
also of being absolutely clear that there's no product support outside
of certified OS platforms.
I'd speculate that IBM JDK and VMware are probably less-extreme cases in
every way, though you should check for yourself.
Often, you'll find that, where there _are_ peculiar dependencies on
particular distributions / versions, someone has already created an
(alleged) solution, which you can try with little cost other than a bit
of your time. For example, for VMware on Debian, this guy said he wrote
some routines to install vmware from the .tar.gz archive, and also to
cleanly remove it:
http://lists.debian.org/debian-hurd/1999/debian-hurd-199907/msg00071.html
(Despite the URL, this is for the Linux kernel, not HURD.)
I found a number of other Google hits on "vmware debian": That's just
the first one that caught my eye as potentially useful.
> 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 ?
This approach is frequently used for proprietary applications whose
licence either lacks the right of redistribution or restricts modified
binaries (e.g., pine/pico, qmail).
--
Cheers, "This is mad, egotistical, sick, twisted, and stretches the bounds of
Rick Moen good taste right off the tongue, past the uvula, and down around
rick at domain linuxmafia.com the duodenum. It has other merits, but that should
indicate positive interest." -- The Cube, http://www.forum3000.org/
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:18:47 GMT