Home / Hardware and QEMU / Encapsulating an App in a Linux Directory Like Mac OS X Packages

Encapsulating an App in a Linux Directory Like Mac OS X Packages

Note: If you want to download an App that has all this encapsulation stuff worked out, take a look at Levinux. It’s only a 15MB download.

Okay, the day is winding down. I’m determined to get the first half of this Linux QEMU encapsulation project done. There are two set of dependencies you must think about for making QEMU portable. The first is all the support files that the QEMU make install process itself installs in your /usr/local path. I grabbed the mess-of-a-message that make install created, but there is a better way. Just use a DESTDIR on make install, and so I re-did the install with this command:

make install DESTDIR=/home/username/Desktop/qemu-linux/

Now, I’ve got the /usr/local directory structure expected by the QEMU binary all collected up in a folder on my desktop that I am free to surf. First thing, get the size! 15.8 MB. Okay, not terrible. That doesn’t include the hard drive image from Tiny Core Linux, which is an additional 8.3 MB, for a total of 24.1 MB. Still acceptable for what I’m trying to accomplish.

Okay, now I’m going to try to accomplish something here which is as close to OS X software .app file bundles or packages as I can do on Linux without additional support software. Apple lets you do this neat little trick that I was doing on the Amiga Computer back in 1989, thanks to a guy named Howard Harrison and a program he wrote at my behest, called WBScript. Now, Amiga computers had icon files that were separate from the programs or folders they attached to, so you could do this really neat trick of attaching an application icon to a folder, then telling it to run an application INSIDE the folder, which thanks to WBScript, could be a batch file. See? You make a single atomic unit that looks and feels like a single file, but really it’s a complete folder that you drag around when you move it, carrying all its dependencies, but runs like a program when you double-click it.

Apple formalized such behavior in OS X by renaming your folder with a .app extension. And so my plan will be to have three things you can click inside a Levinux folder—one for Mac, one for Linux and one for Windows. Since Apple is the only one that formalized this neat little trick, I will be renaming the usr directory I just created as Mac.app. I will put two other folders NEXT to it, a Linux.sh and Windows.bat. Okay, done. So even though it’s going to take me a bit longer to get around to the Windows and Mac binaries and support files, I have placeholders there as a constant reminder to get around to it.

The folder I had previously named “qemu-linux” I’m now renaming Levinux, and inside that I have Mac.app (previously /usr/), Linux.sh and Windows.bat. Underneath Mac.app, I’m going to change “/local/” to “/linux/” and put a “/mac/” and a “/windows/” folder in there as directory placeholders. There’s a very strong concept here that I’m replacing local with the platform name. So, whenever I see a all lower-case folder with a platform name, I know I’m looking at the new /usr/local location, which I will be linking to. I hope this linking trick works with Windows. I know it will with Mac’s, sicne they’re basically Unix computers. Oh yeah, and one more thing: I’m dropping the Levinux directory onto Dropbox, which I have installed on all my daily my Linux, Windows and Mac desktop systems. Now, I can basically massage it into place from all platforms on one master copy.

Okay, this is great progress. I will be separating all the resource files for each platform. If I find out they are indetical, I will deal with that later. Even with the extra file bloat, it’s going to be quite small. But now, my mission is to make a double-click on Linux.sh run QEMU with the Core-current.iso file from Tiny Core Linux. FIrst, I drag that ISO file into the Mac.app file. So, now there’s three “local” folders in there (one for each platform) AND the CD-ROM drive image. Later, that will be the hard drive image, and perhaps a externalized kernel image.

The contents of Linux.sh is now:

cd ./Mac.app
./linux/bin/qemu-system-i386 -curses -cdrom Core-current.iso

…which I had made executable with a chmod +x Linux.sh

I double-clicked it, and it prompted whether I would like to: “Run in Terminal”, “Display”, “Cancel” or “Run”.

The right answer in this case is Run in Terminal. This is a little bit of an issue, because I would prefer just a smooth double-cllick and run scenario. There are other ways to get a double-click to run on Linux desktops, such as a Gnome Launcher file or an Ubuntu Unity .desktop file. But those start to hardwire the launching mechanism to particular Linux windows managers, which I would like to avoid. I may just have to deal with that with a README file. Or just discovery. If one answer doesn’t work, try the other. Another issue is that you can’t control the size of the terminal window that pops up. It’s going to use the user’s default terimal window size, which for most users will be fine, but I have very tall terimal windows. Google… ? Oh, wow, I can just put:

resize -s 25 80

…at the top of my bash scripts! Nice.

Okay, my next step in encapsulating QEMU is making it find its files in its own directory rather than the master /user/local location. That’s going to be done with symbolic links, and the day is over. And on my subway ride home, I’ll read about symbolic links and the Encap Package Management System that I’m modeling this off of. .