Error logs indicate the system needs Java for the package installer to work properly. As verified and documented below, it does not; it only needs a “framework folder” containing some reference information and will work just fine without a JRE, JVM, JDK, or any other part of Java.
Attempts to install anything from a *.pkg results in “Installer quit unexpectedly.” error message.
Below is a snippet taken from multiple error logs resulting from trying to install different packages (two 3rd party apps, two Apple developer downloads, one OS X update, and one Oracle Java update). All six pkg installations failed with error logs containing these same lines.
The problem… a few weeks ago I scrubbed the system of all traces of Java that I could find. In light of all the recent Java exploit news, I wanted to test how complicated it would be to completely purge Java from the system; and I wanted to see if doing so would bring any unexpected consequences. Well, removing all traces is complicated (and difficult to verify with certainty). Although everything on the system continued to work fine, at first, there are unexpected dependencies… such as Apple referencing a Java Framework within their package installer.
Given the amount of “stuff” Apple OS X inherited from Sun Solaris over the years, this shouldn’t come as too big a surprise. Sun used to regularly hard code Java Library dependencies into products which didn’t actually need them. While the text of the error messages are different (but not by much), this is the exact behavior encountered installing certain Sun applications from the command line on headless servers… i.e.., the server had absolutely no reason to load a graphical environment, but the software installer was hard coded to look for the Java GUI packages. For environments where security policies forbid unnecessary packages, we’d isolate the server, load the extra packages, complete the installation, and the remove the unnecessary packages… after the initial install/config was worked out, the organization would use DR processes to build new instances (eliminating the need to keep fiddling with those GUI packages).
ByTheWay, command line “Installer -vers” outputs “… v. 1.5.0 Copywright (c) 1999-2006 … ” That does match up with the time frame when code was being merged into OS X 10.4 from Solaris 10.
The fix… well, four of the above package installation attempts were attempts at fixing. This is why hard coding dependencies is a bad idea; attempting to install a package that would solve the problem requires the referenced package, and fails. After some research (and documentation of activity thus far), I tried another command line
oops… got ahead of myself there. That one may have been like swatting flies with a canon and I’d intended to try various command line options on the java packages first. It’s done and requesting system restart now. Didn’t matter, it didn’t solve the problem. The framework was not restored and normal package installations are still failing.
Next I tried some other command line combinations and also tried extracting the packages to see if the frameworks could be manually located. No joy with either approach.
Running out of options, but before I tried any of the operating system recovery / re-installation choices, I’ll try restoring the framework from TimeMachine.
Looking thru my backups, I found \System\Library\PrivateFrameworks\JavaLaunching.framework (and \JavaApplicationLauncher.framework) from a few weeks ago and restored the folder to it’s original location.
Result… restoring just 375KB of framework folders fixed the problem and the OS X package installer is working again. It was not necessary to restore/install a JRE or JVM or any other part of Java. It just needed required folder containing references to a Java framework. Installer doesn’t need Java and it doesn’t use Java, but it was hard coded to require the presense of a symbolic reference.
Moral of the story…
- Java – annoying.
- hard coding artificial dependencies – shouldn’t be allowed to escape unit testing let alone make it into GA production release software.
- backups which work and provide options for partial restores – everyone should have them.
- Even simple steps for hardening a consumer operating system quickly become complicated, but can usually be resolved without to much fuss.
- Code templates with a lot of “# Includes” may be convenient for developers but often
- present a headache for users – by creating required dependencies which should have been optional.
- introduce vulnerabilities – by requiring components which aren’t necessary in the target deployment environment.
- present long term maintenance problems – by making an entire application dependent on something which should have been an optional feature.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
