How to package VMWare Server for Slackware?

Randux · 07-21-2008, 10:55 AM

Hi guys,

I downloaded VMWare server and expanded the tarball. It is a bloody mess of PATHs that don't come close to either making any sense or fitting into the Slackware way.

Does anyone know how to unravel this tarball into a reasonable structure? I was going to use makepkg after building everything in /tmp but the installer creates such an awful mess I can't figure out what it's doing.

This may be a special job for AlienBob/gnashley/Robby

Thanks if anyone can help.

trickykid · 07-21-2008, 11:10 AM

It might be against VMware's TOS or License to manipulate or redistribute their source code. At least I've never seen any specific VMware Server packages created for Slackware.

But then again, VMware is not GPL software and it's tarball is usually filled with binaries, kind of like the Firefox download. You download, untar to directory you want to run from and you're done. You'll probably have to create custom startup scripts for it though for Slackware, which is pretty easy once you get it running.

Randux · 07-21-2008, 11:42 AM

I didn't ask about manipulating or redistibuting anything. I do get to say what I install on my box and where.

I'm just trying to figure out their bizarre library "structure" like why they have /bin/lib/bin and so on

I don't have any plans to just allow their installer to wreak havoc on my system!

trickykid · 07-21-2008, 11:46 AM

Quote:

Originally Posted by Randux

I didn't ask about manipulating or redistibuting anything. I do get to say what I install on my box and where.

I'm just trying to figure out their bizarre library "structure" like why they have /bin/lib/bin and so on

I don't have any plans to just allow their installer to wreak havoc on my system!

Just how they wanted to put their package together. Sometimes it makes sense, other times it doesn't.

The only reason I say redistribute is if someone did build a custom Slackware package and placed somewhere on a mirror site or linuxpackages.net, that's redistributing in a sense. It's probably one of the reasons most haven't done so. But I'd read their license agreement before doing so, I'm just assuming since I have yet to find one repackaged for Slackware and yet to see a mirror for Fedora or Red Hat with yum, etc.

Randux · 07-21-2008, 11:55 AM

Sorry, I see your point now. I guess if someone was really over the top he could write a script to clean up this mess and create a regular package. I can't believe anyone would allow this ugly baboon on their system as is. It almost makes you want to use Windows....NOT!

Thanks,

Rand

gnashley · 07-22-2008, 03:37 PM

Everyone knows that flattery will get you... everywhere. I was feeling up to a challenge today so I took this on. I downloaded both VMware-server-1.0.5-80187.i386.rpm and VMware-server-1.0.5-80187.i386.tar.gz to see whcih would be easier to work with. In this case, I think the rpm makes an easier target. All the mess with the directory arrangement is basically legal -comparable to the way mozilla/seamonkey installs, with nearly the whole mess under usr/lib/vmware.
Anyway, I proceeded to throw thw rpm at src2pkg and got a surprise -the 'disrpm' tool included with src2pkg choked on the ropm format -the first time I have seen this happen- usually disrpm works when other tools don't! So, I had a look at the tar.gz archive but didn't like what I saw. So, instead, I used rpm2tgz to first convert the rpm to tgz format. Then I threw that at src2pkg and -Bingo! But there were a couple of src2pkg defaults which I thought ought to be overridden in this case.
1. The package installs perl modules so we need to override src2pkg's removal of empty files with FORCE_ZERO_LENGTH=YES
2. The package installs docs to /usr/share/doc/vmware and I'm pretty sure that the program looks for them specifically there in order to show the EULA. So we need to override src2pkg's correction of document paths with CORRECT_DOCS=NO
3. The package installs debug binaries so we need to disable stripping of binaries. It probabyl needs the libraries unstripped as well, so we need to disable that as well. (stripping everything only saves 7MB anyway). So we need:
STRIP_BINS=NO and STRIP_LIBS=NO

So, after using rpm2tgz on the rpm archive we have VMware-server-1.0.5-80187.i386.tgz
Unfortunately all the src2pkg overrides needed are seldom-used ones so they are not included in the src2pkg command-line options. Still, you can do the whole thing from the command line like this:

Code:

FORCE_ZERO_LENGTH=YES; CORRECT_DOCS=NO; STRIP_BINS=NO; STRIP_LIBS=NO; src2pkg VMware-server-1.0.5-80187.i386.tgz

But you'd probably better use a script with those options so you don't forget what was needed:

Code:

#!/bin/bash
## src2pkg script for: 	vmware-server
## src2pkg Copyright 2005-2008 Gilbert Ashley <amigo@ibilio.org>

SOURCE_NAME='VMware-server-1.0.5-80187.i386.tgz'
ALT_NAME='vmware-server'
VERSION='1.0.5'
# ARCH='i386'
BUILD='1'
PRE_FIX='usr'
# Any extra options go here
# EXTRA_CONFIGS=''
# STD_FLAGS='-O2 -march=i486 -mtune=i686'

# we need this because this package installs perl files
FORCE_ZERO_LENGTH=YES
# we need this because the program looks for the EULA 
# in /usr/share/doc/vmware
CORRECT_DOCS=NO
# These are optional. Allowing src2pkg to strip the bins and libs
# saves 7MB in the final package, but some of the included bins
# are debug binaries and won't work if they are stripped. Plus,
# some of the included libs might aalso be broken if stripped
# better not strip anything
STRIP_BINS=NO
STRIP_LIBS=NO

# Get the functions and configs
. /usr/libexec/src2pkg/FUNCTIONS ;

# do_all_processes can substitute these 16 steps:

pre_process
find_source
make_dirs
unpack_source
fix_source_perms
configure_source
compile_source
fake_install
fix_pkg_perms
strip_bins
create_docs
compress_man_pages
make_description
make_doinst
make_package
post_process

There may be some extra steps needed for configuration which could or should be incorporated into the doinst.sh file, but you'll have to run the program and work with it in order to be sure. If so, let me know what was needed and I'll see about writing them into the doinst.sh (the one src2pkg generates should cover the basic needs of the installation including creating links and installing '*.new' configuration files.

The command line usage above is a good example of how to access *any* of the src2pkg options which are not included in the regular command-line options.

acummings · 07-24-2008, 02:09 AM

Quote:

could write a script to clean up this mess and create a regular package.

Vmware Workstation trial and Vmware Player both (used to not long ago anyways) have an uninstall (feature/option)

dunno how cleanly it does so. (Perl [the uninstaller] is powerful though)

Not yet tried Server so cannot speak for it -- but I'd be surprised if it is without an uninstaller.

Ok, so now then, (begs the question perhaps) what's a package? Whose package? What is meant by "package"? How does "package" need to look? What are characteristics of "package? Vmware's or Slackware's? Or, other, for that matter. Package ie Debian, Fedora, or what's the name of the popular distro with the Perl programmed package management system

Or, better yet, go with the venerable src2pkg

(in this case it's a bin2pkg operation though)

Thanks Gnashley.

Randux · 07-24-2008, 02:37 AM

Quote:

Originally Posted by gnashley

Everyone knows that flattery will get you...
everywhere.

Wow that's really great, thanks so much gnashley! While you were doing this I was having another go at unravelling this in /tmp. It crashed building the kernel module (running the 2.6.17.13 kernel from Slack 11) and didn't have time to get back to it. To be honest I will have to read your post a few hundred more times as I don't really think I understand it yet.

There is supposed to be some patch for vmware server but it's for a 2.6.22 kernel. I don't know if it will work or not.

As for you, acummings, we all use tools like checkinstall and src2pkg to make Slackware packages we can use on our systems and based on Pat's library structure. If you haven't had a look yet at the vmware abomination, you can't imagine how bad their installer is. Whether or not they have an uninstaller is not really the point; I've built hundreds of my own packages from compiling or untarring other stuff and I don't allow installers to slather rubbish all over my systems!

gnashley is one of the acknowledged package Kings since he's written various tools to build and work with packages.

Thanks again!

Rand

acummings · 07-24-2008, 03:21 AM

"One person's junk is another person's treasure"

That is totally all that I was about, formerly.

Quote:

I don't allow installers to slather rubbish all over my systems

I'm fully aware what Vmware workstation trial and vmware player does.

And I won't argue (against) that on Slackware it's a mess. (I run Slackware)

Vmware primarily for other distros, not Slackware.

Slackware is not a supported distro by Vmware.

Since Vmware target certain distros, I seriously doubt that *on those particular specific Linux distros* (not Slackware) that it's considered like a mess ie slather rubbish everywhere -- rather, it's likely considered as they are doing it in a logical and efficient way, ie they have their reasons for doing it the way that they do.

(their method does not align with the way that Slackware does things)

I use build scripts and sometimes scrc2pkg. It's really rare to non existent that I install anything other than the .tgz Slackware package.

So, therefore, (for me, I'll own this next one),

(for me this is trial or testing mode whereby I do a disk image beforehand) And, really, who gives a rip (at least I don't care) if only one app puts stuff all around as long as that same app's uninstaller keeps track of it all and I run such app's uninstaller when I want the app gone.

I always have a disk image taken before trial/testing that I can restore anyways whenever the rare occasion I might trial in that fashion.

"One person's junk is another person's treasure"

That is totally all that I was about, formerly.

1. Ask a Fedora programmer what a software package needs to look like (sysv startup system, etc. etc.)

2. Ask a Debian programmer what a software package needs to look like.

3. Ask a Slacker what a software package needs to look like.

Welcome to "One person's junk is another person's treasure" (replies to # 1, 2, and 3 will disagree on how to junk (wreck or have a poor) package versus what's treasured ie in the way of the layout of where things install to, etc.

Vmware targets certain distros, has their reasons for why they go the way that they do.

--
Alan.