LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 12-20-2012, 01:52 PM   #1
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,260

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
VirtualBox 64-bit slackbuild script


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.
 
Old 12-20-2012, 05:19 PM   #2
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.0, 13.1, 13.37, 14.0, 64-14, -current
Posts: 1,511

Rep: Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509
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.
 
Old 12-21-2012, 07:04 AM   #3
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 2,873

Rep: Reputation: 700Reputation: 700Reputation: 700Reputation: 700Reputation: 700Reputation: 700Reputation: 700
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?

Last edited by tronayne; 12-21-2012 at 07:15 AM.
 
Old 12-21-2012, 11:47 PM   #4
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 462

Rep: Reputation: Disabled
I second tronayne's comments.
 
Old 12-28-2012, 10:58 AM   #5
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,652

Rep: Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736
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
 
Old 01-03-2013, 02:17 PM   #6
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,260

Original Poster
Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Quote:
As a side note, the provided uninstall.sh is good but not perfect:
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.
 
Old 01-03-2013, 03:13 PM   #7
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, Slackware64
Posts: 1,412

Rep: Reputation: 631Reputation: 631Reputation: 631Reputation: 631Reputation: 631Reputation: 631
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
 
Old 01-03-2013, 03:25 PM   #8
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.0, 13.1, 13.37, 14.0, 64-14, -current
Posts: 1,511

Rep: Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509
Quote:
Originally Posted by Woodsman View Post
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 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.

Quote:
Originally Posted by kikinovak View Post
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.
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.
 
Old 01-03-2013, 08:34 PM   #9
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,260

Original Poster
Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Quote:
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.
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.

Quote:
So what we are talking about is repackaging the 64 bit pre-compiled version from the Oracle installer to avoid that requirement.
That's correct.

Last edited by Woodsman; 01-03-2013 at 08:35 PM.
 
Old 01-03-2013, 11:49 PM   #10
ppr:kut
Member
 
Registered: Aug 2006
Location: Netherlands
Distribution: Slackware
Posts: 353

Rep: Reputation: 89
Quote:
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.
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.
Old 01-04-2013, 01:30 AM   #11
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.0, 13.1, 13.37, 14.0, 64-14, -current
Posts: 1,511

Rep: Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509
Quote:
Originally Posted by ppr:kut View Post
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.
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!
 
Old 01-04-2013, 02:46 AM   #12
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,652

Rep: Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736
Quote:
Originally Posted by Woodsman View Post
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.
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:

Code:
# Start vboxdrv
# If you do not wish this to be executed here then comment it out,
# and the installer will skip it next time.
if [ -x /etc/rc.d/rc.vboxdrv ]; then
    /etc/rc.d/rc.vboxdrv start
fi

# Start vboxballoonctrl-service
# If you do not wish this to be executed here then comment it out,
# and the installer will skip it next time.
if [ -x /etc/rc.d/rc.vboxballoonctrl-service ]; then
    /etc/rc.d/rc.vboxballoonctrl-service start
fi

# Start vboxweb-service
# If you do not wish this to be executed here then comment it out,
# and the installer will skip it next time.
if [ -x /etc/rc.d/rc.vboxweb-service ]; then
    /etc/rc.d/rc.vboxweb-service start
fi
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:

Code:
find /etc /lib /opt /usr ! -type d -print > files_before
Then I run the VBox installer and run the following two commands immediately afterwards:

Code:
find /etc /lib /opt /usr ! -type d -print > files_after
diff files_before files_after | sed -n 's/^> //p' > vbox_install.log
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.:

Code:
cat vbox_install.log | xargs -d'\n' -n1 rm -v
Quote:
Originally Posted by Woodsman View Post
I'm a bit surprised that everybody responding here treats the problem so non chalantly.
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.
 
Old 01-04-2013, 02:55 AM   #13
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,652

Rep: Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736Reputation: 736
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:

Code:
sh VirtualBox-4.2.6-82870-Linux_amd64.run --noexec --target vbox-files
The directory 'vbox-files' will be created, containing the following:

Code:
deffiles
install.sh
LICENSE
routines.sh
uninstall.sh
vboxautostart-service.sh
vboxballoonctrl-service.sh
vboxdrv-pardus.py
vboxdrv.sh
vboxweb-service.sh
VirtualBox.tar.bz2
Have fun reading!
 
Old 01-04-2013, 07:59 AM   #14
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 2,873

Rep: Reputation: 700Reputation: 700Reputation: 700Reputation: 700Reputation: 700Reputation: 700Reputation: 700
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:
Code:
VirtualBox-4.2.6-82870-Linux_amd64.run
(http://download.virtualbox.org/virtu...inux_amd64.run)
Oracle_VM_VirtualBox_Extension_Pack-4.2.6-82870.vbox-extpack
(http://download.virtualbox.org/virtu...0.vbox-extpack)
Think about it: you can install Windows XP in a virtual machine on a Slackware 64-bit platform!

Hope this helps some.
 
Old 01-04-2013, 12:07 PM   #15
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,260

Original Poster
Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Quote:
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.
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.

Quote:
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.
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can't compile wxPython Slackbuild in 32-bit (but works fine for 64-bit) Eldarby Linux - Software 7 07-29-2012 12:00 PM
[SOLVED] Cannot install fpc 32 bit on 64 bit multilib slackbuild. george-lappies Slackware 8 05-26-2011 09:37 AM
Virtualbox 4.0.4 slackbuild for slack 13.37 Barx Slackware 4 05-07-2011 11:44 AM
Virtualbox 2.1.2 Slackbuild TL_CLD Slackware 23 02-18-2009 05:25 AM
VirtualBox.SlackBuild problems joegumbo Slackware 2 09-01-2008 01:44 PM


All times are GMT -5. The time now is 10:42 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration