Tag Archives: installer

Office 2008 update includes Entourage EWS

Not that the [release notes have any mention of it][1], but the [Microsoft Office 2008 12.2.5][2] update will also install the latest [Entourage EWS 13.0.5][3] if you had it on your hard disk already (else you get vanilla Entourage updated). You only need to install the stand-alone update if this is the first time you are installing the Exchange Web Services version of Entourage.

Microsoft’s Mac installers are good, but unnecessarily complicated. And the design of the [Mactopia website][4] drives me up the wall – tiny little scrolling `

` blocks and javascript hyperlinks makes it difficult to read the information and difficult to link straight to an update.

[1]: http://support.microsoft.com/kb/2028864
[2]: http://www.microsoft.com/mac/downloads.mspx?pid=Mactopia_Office2008&fid=D46255BD-6470-4106-9FE2-EA67ACD3F1BD
[3]: http://www.microsoft.com/mac/downloads.mspx?pid=Mactopia_Office2008&fid=EC991D3B-6B25-41C3-9119-D0E6985F2FC1
[4]: http://www.microsoft.com/mac/

The hidden depths of Adobe CS4

[Adobe][adobe]’s installers and updaters for the Creative Suite are amazingly bad. The updaters actually create a hidden directory `/Applications/.AdobePatchFiles` and store what I assume are the old versions of the files that get updated. Almost a gigabyte of data on my system!

What the fuck is wrong with [these guys][oobe]?

Not certain which is worse, that the updaters created a folder in `/Applications` that clearly belongs somewhere in `/Library/Application Support` (if it should exist at all) or that they made it hidden.

You can delete it.

[adobe]: http://www.adobe.com/
[oobe]: http://blogs.adobe.com/OOBE/

Crazy Acrobat installers love Python

Looking through the updaters for [Adobe Acrobat][acrobat] 9 for Mac I came across a bunch of scripts written in [Python][python]. My favourte was called `FindAndKill.py`:

#!/usr/bin/python
“””
Search for and kill app.
“””
import os, sys
import commands
import signal

def main():
if len(sys.argv) != 2:
print ‘Missing or too many arguments.’
print ‘One argument and only one argument is required.’
print ‘Pass in the app name to find and kill (i.e. “Safari”).’
return 0

psCmd = ‘/bin/ps -x -c | grep ‘ + sys.argv[1]
st, output = commands.getstatusoutput( psCmd )

if st == 0:
appsToKill = output.split(‘\n’)
for app in appsToKill:
parts = app.split()
killCmd = ‘kill -s 15 ‘ + parts[0]
#print killCmd
os.system( killCmd )

if __name__ == “__main__”:
main()

(You can [download the Acrobat 9.1.3 update][acrobat913] and find this script at `Acrobat 9 Pro Patch.app/Contents/Resources/FindAndKill.py`.)

Was the author not aware of the `killall` command for sending a kill signal to a named process? The [`killall` man page][mankillall] says it appeared in [FreeBSD 2.1, which was released in November 1995][fbsd]. Adobe CS4 was [released about 14 years later][cs4]. How is it Adobe’s product managers approve these things for release?

What is particularly galling about Adobe’s Acrobat 9 updaters is that they seem to re-implement so much of what the Apple installer application does, even down to their use of gzipped cpio archives for the payload.

[acrobat913]: http://www.adobe.com/support/downloads/detail.jsp?ftpID=4538
[acrobat]: http://www.adobe.com/products/acrobatpro/
[python]: http://www.python.org
[mankillall]: http://www.manpagez.com/man/1/killall/
[fbsd]: http://www.freebsd.org/releases/2.1R/announce.html
[cs4]: http://www.adobe.com/aboutadobe/pressroom/pressreleases/200809/092308AdobeCS4Family.html

Munki and watchedinstall

[watchedinstall][watchedinstall] by [Preston Holmes][ptone] is a tool to monitor what files an installer actually installs. It works for pkg formats and most interestingly it works for custom install applications (i.e. InstallerVise reactionaries).

[Munki][munki] is [Greg Neagle][neagle]’s suite for keeping a bunch of Macs up-to-date with a centrally managed software manifest. I literally *dream* about this kind of problem and how best to cover all the various things one wants to do when managing software on a Mac network.

Somewhat bitter-sweet dreams. I think Macintosh management is interesting, but why couldn’t I have dreamt about girls?

[watchedinstall]: http://ptone.com/dablog/2009/07/watchedinstall/
[ptone]: http://ptone.com/dablog/
[munki]: http://code.google.com/p/munki
[neagle]: http://managingosx.wordpress.com/

Me and Adobe hates you

It’s not true, I don’t hate you, but the [Adobe CS4][cs4] installer does.

I was installing Adobe Creative Suite 4 today on a Macintosh. I had the amazing Adobe CS4 Master Collection media to install from, but all I needed was the Illustrator, InDesign, Photoshop and Bridge. So in the installation process I choose a custom install and de-select most everything except those applications. I un-ticked After Effects because I didn’t want to install After Effects. I un-ticked Soundbooth, I un-ticked Dreamweaver, I un-ticked all them other applications.

The installation process begins. Finally it finishes. Afterwards I had Illustrator CS4, InDesign CS4, Photoshop CS4 and Bridge CS4 installed on my Mac’s hard drive. They all worked a treat.

I also had a dog’s dinner of all the other flipping applications installed, all the applications I did not want to install, I had little vomit stains of Adobe installations that didn’t quite actually install, but installed.

So for example I had a new folder in the Applications folder called “Adobe After Effects CS4” and inside there was an application named “Adobe After Effects CS4.app”. Except it isn’t an actual flipping application. It has a great big no entry icon on it because it isn’t an actual executable application.

CS4 installation mistake

In one sense the installer did what I expected: it did not install a usable After Effects CS4. In another sense it effing ignored what I expected by creating an installation folder for After Effects CS4 and then created an incomplete stub of the After Effects CS4 application.

I wish the Adobe CS4 installer had just done what I asked for. [The Adobe installation and licensing blog is here][oobe].

[oobe]: http://blogs.adobe.com/OOBE/
[cs4]: http://www.adobe.com/products/creativesuite/

Installers: correlate of hate

The degree of hatefulness for a Mac installer often correlates to the degree of hatefulness for the software it installs. [Adobe Creative Suite][adobecs] is this rule’s exemplar. And if you have a [Blackberry][blackberry] mobile phone you may have had fun trying to get the [PocketMac for Blackberry software][pocketmac] working.

The PocketMac installation experience is pretty poor. Not surprisingly it uses [Mindvision’s Installer Vise][installervise]. But the developers have really pushed the boat out and gone to the trouble of using an Apple installer package icon for the install application. Do not be deceived! It is an application, not a package.

The PocketMac installer

The PocketMac installer

And if you succeed in installing the sync application, don’t expect it to work unless you happen to have learnt that you should only connect the Blackberry to the USB cable *after* you have opened the sync application.

[adobecs]: http://www.adobe.com/products/creativesuite/
[blackberry]: http://www.blackberry.com/
[pocketmac]: http://na.blackberry.com/eng/services/desktop/mac.jsp
[installervise]: http://www.mindvision.com/macvise.asp

Fiery RIPs, old-fashioned installation hate

Whether you buy from Canon or Xerox (or Epson or Konica Minolta, etc.), if you are buying a printer for heavy-duty use in a Mac design studio then it will probably have a Fiery RIP[^1] manufactured by [Electronics For Imaging][efi].

There are lots of things to hate about Fiery RIPs.

But right now I am going to hate their backward attitude to Mac driver installation. It is the year 2009 and this lot have yet to supply drivers as anything other than [Installer Vise][vise] applications. So that means no simple command-line roll-outs with [Apple Remote Desktop][ard]. That means no way of looking at the installation manifest ahead of installation. No way of having any confidence that the installer won’t screw everything up.

To compound their sins, EFI like to give their installer applications a very pretty icon that looks just like a stylized Apple installer package. It is a very pretty icon of a box; a box full of hate.

Purple box of Installer Vise hate

Purple box of Installer Vise hate

[efi]: http://www.efi.com/
[vise]: http://www.mindvision.com/macvise.asp
[ard]: http://www.apple.com/remotedesktop/

[^1]: RIP stands for Raster Image Processor. Which leads to quite enjoyable conversations about ripping through pages.

Installer sympathy for Linux

Nice to see [the installation process on Linux][rpm] can be [as misguided as it is on Mac OS X][installer].

> The irritating thing about these system manglings is that by and large they’re unnecessary, especially things like the JDK ugliness. These companies are not running into novel problems in building RPM packages, and other software manages to do the right thing. The companies were just lazy. (And because of the license terms of their software, outsiders can’t fix the problem, build proper packages, and distribute the results.)

[Chris Siebenmann’s blog, Wandering Thoughts][chris].

[rpm]: http://utcc.utoronto.ca/~cks/space/blog/linux/BadRPMPackaging
[installer]: http://reliablybroken.com/b/tag/installer/
[chris]: http://utcc.utoronto.ca/~cks/space/blog/

Adobe AIR installer, a hateful tradition

[Tweetdeck][tweetdeck] seems to be the path of least resistance for a desktop
[Twitter][twitter] client on Mac OS X 10.4 (there are other free Mac desktop
clients, [Nambu][nambu] and [Tweetie][tweetie] but unfortunately they both
require 10.5).

But Tweetdeck requires the [Adobe AIR runtime][air]. And the Adobe AIR 1.5
installer takes Adobe’s favourite approach of ignoring Mac OS X’s package
installer format in favour of a custom installer application.

When you open the installer, it takes a few seconds and then gives you a
license agreement. Here’s an excerpt:

> 2.3 Distribution. This license does not grant you the right to sublicense
> or distribute the Software. For information about obtaining the right to
> distribute the Software on tangible media or through an internal network or
> with your product or service please refer to…

I read that as explicitly banning any efforts to create a package
to ease the pain of deploying AIR across a bunch of Macs. Damn it.

Clicking Accept moves you to the installation proper, and Adobe loses a few
more points by immediately throwing up an authentication dialog box. Why does
this dialog appear? What am I about to install? If only this was a package
installer I could have looked at the installation manifest to get an idea of
what was going to happen *before* granting the installer free rein to my
computer.

Turns out that everything you care about is installed in `/Library/Frameworks/Adobe AIR.framework` and `/Applications/Utilities/Adobe AIR Application Installer.app` and `/Applications/Utilities/Adobe AIR Uninstaller.app`. For some reason the installer also touches a couple of files in `/Users/Shared/Library/Application Support/Adobe/AIR/Updater` and slips a couple utility apps in your `Library` somewhere. You can ignore those.

It feels particularly wrong when non-system applications put things in the `Utilities` folder – it is effectively a special system directory, and its contents are tools for tinkering with the system configuration or for diagnostics. Adobe Creative Suite 3 likes to create a folder `Adobe Installers` in there *and* `Adobe Utilities`, just in case you haven’t worked out how much you need their software on your computer.

Heaven is almost certainly running System 6.0.8. Nothing is installed without [Font DA Mover][fontdamover].

[air]: http://www.adobe.com/products/air/
[tweetdeck]: http://www.tweetdeck.com/
[nambu]: http://nambu.com/
[tweetie]: http://www.atebits.com/tweetie-mac/
[twitter]: http://twitter.com/
[fontdamover]: http://download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/English-North_American/Macintosh/System/Older_System/System_6.0.x/TrueType/

Package installer wish

Mac OS X administrators frequently need to build installer packages to
help deploy and manage software on a network of Macs. The motive for
creating a package is one of

* Packaging software that does not have a dedicated installer. This applies
to all the nice drag-and-drop applications like [Firefox][firefox] and
[Cyberduck][cyberduck].
* Packaging your own site’s software, whether that is as simple as printer
descriptions or as complex as a full-blown application.
* Re-packaging some miserable piece of shit installer that either totally
denies the harsh reality of Apple’s non-cross platform installer formats or
which manages to make such a balls of an install package that you were
better off before they bothered.
[Most everything by Adobe is in this category][adobeinstallers].

The first of those three is very common, and it ought to be easy to
create packages for existing installed applications.
[Apple’s PackageMaker][packagemaker] application provides a nice interface
for creating packages, but it has two drawbacks:

* PackageMaker is not installed by default on Mac OS X (it gets intalled as
part of the Developer Tools).
* Before PackageMaker 3 (part of Xcode 3, which requires Mac OS X 10.5)
there was no *simple* method for quickly packaging an installed application.

What I want is a package creation tool that works on a 10.4 system without
requiring the developer tools and which can be scripted. The `packagemaker`
command-line tool requires an existing `Info.plist` file or `.pmdoc` file
if you want to set a custom default installation directory – not the end
of the world, but tedious.

Useful links
————

* [Iceberg][iceberg] is an excellent graphical tool for building packages, by
Stéphane Sudre who also wrote up the…
* [PackageMaker how-to][pmhowto] which is a very useful introduction to the
details of `.pkg` files. Bit out-of-date these days.
* Man pages for the command-line [packagemaker][man1pm] and for the
[installer][installer] tools.
* Apple’s [software distribution documentation][softdist], which is very
quiet on the subject of custom installer plug-ins. Xcode has a template
project for an installer plugin, and the `InstallerPlugins.framework` headers
have lots of information.
* [Installer-dev mailing list][installerdev], where the people who wrote
the tools and documentation help out a lot.
* [JAMF Composer][composer] which is part of the Casper management tools.
Version 7 is no longer free.

[firefox]: http://www.mozilla.com/firefox/
[cyberduck]: http://cyberduck.ch/
[packagemaker]: http://developer.apple.com/DOCUMENTATION/DeveloperTools/Conceptual/PackageMakerUserGuide/index.html
[adobeinstallers]: http://blogs.adobe.com/OOBE/
[iceberg]: http://s.sudre.free.fr/Software/Iceberg.html
[pmhowto]: http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html
[man1pm]: http://developer.apple.com/DOCUMENTATION/DARWIN/Reference/ManPages/man1/packagemaker.1.html
[installer]: http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man8/installer.8.html
[softdist]: http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution
[installerdev]: http://lists.apple.com/mailman/listinfo/installer-dev
[composer]: http://www.jamfsoftware.com/products/composer.php