Does anybody have a slackbuild script for the non OSE/64-bit version of Virtualbox? I believe the vendor install script has an uninstall function, but a slackbuild script to create a package would be nice.

Thanks.

I recently asked the same question in another thread here, and at this time the answer appears to be no for pure 64 bit systems.

It was pointed out in that thread that there is no OSE/non-OSE divide since version 4.0, which was also news to me.

Like you I would prefer to repackage it, but in the end I used the Oracle installer.

I ran a diff on my directory tree before and after to see what changes were made and kept that, along with the Oracle installer as my "removepkg" method.

I have given thought to writing a slackbuild for it but VB is mostly a novelty for me, not something I actually use much, and I have not had the time to think about it further.

I've been using the binary VirtualBox version for some years; never had a problem removing it (with /opt/VirtualBox/uninstall.sh), 'course, I haven't really removed it more than once three or four years ago but there you are, it can be done. Also, when an upgrade release becomes available, you simply execute the "*.run" and it takes care of stopping the daemon, removing all the existing software (including the kernel modules), compiles the new kernel modules, installs them, installs all the software and you're ready to rock-'n'-roll (you can start it up immediately).

A SlackBuild would be nice but, so far anyway, it's a heck of lot easier to just install the binary and be done with it. If you don't like it it's dirt simple to remove it with the provided uninstall.sh.

Maybe save yourself a lot of time and trouble?

I second tronayne's comments.

Yeah, I always stick use the install method provided by their packages and have found it works really well.

As a side note, the provided uninstall.sh is good but not perfect:

https://www.virtualbox.org/ticket/10752

My point exactly. I prefer a package for reasons discussed in a different thread.

Discovering software that was installed without using the package manager is challenging. The point is not so much the dependability or trustworthiness of non package install scripts, but that knowing what was installed becomes a mess.

I'm a bit surprised that everybody responding here treats the problem so non chalantly.

I exploded the contents of the virtualbox run scripts but I haven't had time to study further as to whether I can write a wrapper build script. The nvidia build script at slackbuilds.org provides an example of such a wrapper script.

VirtualBox only exists in a 32-bit version. If you have a 64-bit Slackware (like I do), install Eric's multilib packages, then build 'virtualbox' and 'virtualbox-kernel' from SBo. Read the instructions first, as there are a few dependencies and caveats.

Cheers,

Niki

I agree on both counts. I can't speak for others, but my own decision to use the Oracle installer was not so much nonchalant as that I could not find a package script and could not easily write one myself.

But I agree with you that a repackaging script would be the best solution.

Actually that is not quite true. As I unserstand it, the 64 bit version still must have 32 bit libraries to host 32 bit virtual machines, hence it will not build on a pure 64 bit machine. So what we are talking about is repackaging the 64 bit pre-compiled version from the Oracle installer to avoid that requirement.

I don't want to BUILD the 64-bit version. I want to INSTALL the 64-bit version. Rather than use the *.run script provided by the Oracle folks, I want a package. I don't want to install full multilibs support for a single program.

Needed to create a package is a wrapper build script, similar to the slackbuilds.org nvidia build script. The basic process is to "unzip" the *.run package contents to a target directory, perform any necessary functions, and then reassemble the target directory contents into a package.

The Oracle folks provide 64-bit packages for some distros, but not Slackware.

That's correct.

This has come up more and more in the past and I do see the point there. When building the 64bit version from source you do need a multilib capable gcc+glibc (nothing more), but only when building so you can remove it again after. I can see why not everyone wants to do that though. So, for some time, I've been planning to host packages of virtualbox for both 32 and 64bit. If that is of interest to you too then give my a couple days and I'll put them up somewhere.

1 members found this post helpful.

Yes that would be of interest to me, and I would appreciate it.

I am trying to avoid adding multi-lib, but also "never" install packages that I do not build myself. As I cannot do that with VB-64 bit I would much pprefer to install your pre-built package than Oracle's, all else being equal!

It doesn't have to be, as long as you make a little effort to understand what these types of scripts do and check that their uninstall routines do actually work as advertised. There are tools to help you, even included within Slackware (e.g. slacktrack). I am quite happy using install scripts provided by software authors for a handful of packages I consider to be worth it, so long as I have satisfied myself that they don't do anything crazy.

The first time I encounter scripts like this I make a judgement call as to what would be fastest for me, making a package or working out how to track what files are installed. This usually involves having a quick scan through the install routine.

If I decide not to bother with making a SlackBuild I do some more investigation to track what is happening using a test environment such as a chroot, an install I don't care about on a spare machine or virtual machine (though you would have bootstrapping problem in this particular case). The actual tracking involves making an initial listing of all files on the system and some key that helps me see if they have been altered (e.g. modification times or an md5sum). Then I install and compare the differences before and after. I also check what happens when you run any uninstall script that has been provided.

In the case or VirtualBox the last time I did a thorough check it seemed that for the most part a bunch of files are placed in /etc, /usr, /lib and /opt. No files were removed and a few pre-existing files do get modified but in reasonable and expected ways, e.g. /etc/rc.d/rc.local has the following added:

The uninstall.sh script does not remove modifications like the one above but as I said it looks sensible and would do no real harm (given it tests for the presence of VBox components before it tries to run them). It also doesn't remove any additional files.

Once I feel confident that the guys who made the install/uninstall scripts know what they are doing I install into my real environment and only do quick, limited checks on subsequent installs/upgrades. For example in the case of VBox I always remove the old copy first and then before I install the new one I run a command like this:

Then I run the VBox installer and run the following two commands immediately afterwards:

vbox_install.log then provides a list of all the new files that were placed down (it does not track modifications to files like /etc/rc.d/rc.local). I can use this to verify that uninstall.sh does its job correctly or I can even use the log file directly to do the uninstall itself, e.g.:

I don't treat it nonchalantly. I feel I am reasonably careful and cautious with regards to stuff like this. It was one of my logs that allowed me to notice the following: https://www.virtualbox.org/ticket/10752 (I checked first for duplicates and searched on the web and nobody else was reporting this, so I figure I am probably more aware of what is going on than most).

At the same time I am not gonna worry about a handful of packages not being tracked by pkgtools.

If anyone wants to extract the contents of a package like VirtualBox-4.2.6-82870-Linux_amd64.run to have a look at install.sh, routines.sh, uninstall.sh, etc. you can issue the following:

The directory 'vbox-files' will be created, containing the following:

Have fun reading!

Folks, you do not need multilib to install the 64-bit binary version of VirtualBox; you do not need multilib to install, for example, 32-bit Slackware in a virtual machine on a 64-bit VirtualBox platform.

The current 64-bit binary (and Extension Pack) is:
Think about it: you can install Windows XP in a virtual machine on a Slackware 64-bit platform!

Hope this helps some.

I'm interested. A wrapper build script using the *.run files would resolve the problem. One note, as the *.run script tampers with the existing rc.local, the wrapper script should create a rc.local.new.

We acknowledged that point early in the thread discussion. The whole point of discussion is to create a package from the *.run scripts, which already include prebuilt files, rather than using the *.run scripts directly.