|
Mac GeekeryGet your geek on. |
|
blog advertising is good for you
recent popular content
User login
|
…or: how I learned to hate Installer VISE. In my previous article I described a mehodology for mimicing the functionality of the Windows “Power Users” group. Between implementing this and implementing directory-based accounts I have learned one valuable lesson: people who use Installer VISE (or some other malformed 3rd party installation application) need to be slapped upside the head. There are a couple reasons for this. The first being that all too often such installers don’t operate under the same rules as Apple’s built-in installer, which will simply say “Hey, I need to operate with these privileges. Hey, SecurityAgent! Auth me, baby!” . They will complain you’re not an admin, even though you are, and not even let you enter the appropriate credentials to authenticate the installation. What they’re complaining about is you’re not a LOCAL account that’s a member of the admin group, and they will stubbornly stick to that narrow definition. This, of course, is a problem. It requires you to log in with a local admin account. This flies in the face of everything that OS X is: a (relatively) secure UNIX-based multiuser system. The beautiful thing about OS X is you should not need to be logged in with a local admin account EVER. The second problem is a matter of convenience for sysadmins. Dear publishers, I really hate repackaging your crappy installers so that I can deploy your app in my environment. No love, Sketch And as a side rant, as long as I’m talking about things that don’t play nice with OS X: Developers, OS X is a MULTIUSER operating system. M-U-L-T-I-U-S-E-R. I know you’ve been making this app since the days of System 7, but it’s now 2007. Catch up. Stop putting your essential components in the installing users home folder and put it where it belongs in the all users library. I’m going to point out a couple “Worst Offenders” as examples of what I’m ranting about:
The bottom line is this (meet me at camera 3), if you’re making an app, remember that this isn’t OS 9. This is OS X, and the account logged in may not be a local account that’s a member of the local Admin group. Your installer should play nice with this arrangement, and so should your app. You guys who make regular .PKG and .MPKG installer files aren’t completely off the hook either. Unless an app is being installed in a user’s home directory you might want to think about running a post-install script to set ownership to root:admin and permissions to 775, since Installer typically leaves ownership at the user who installed the app unless you specify otherwise in your package.
About Sketch
Author Biography Is “The Mac Guy” for a private university, and proud Mac geek since 1994 |
I feel your pain…
(another “Mac Guy” for a private university)
Top shelf article, Sketch. I agree all the way.
If an application install is complex enough to need an installer, then it needs an uninstaller. Apple seems to be exempt in that they never expect you to remove one of their products, and God help you if you move an Apple App after install and they send you an update.
Third party applications that need installers need uninstallers, and Apple offers nothing here. There are also the details that Apple is completely uninterested in fixing installer bugs unless they affect Apple directly, and even less interested in fixing bugs in “legacy” systems like Panther. If Apple wants third parties to use the Apple installer, they need to fill some serious support and functionality holes.
Microsoft’s MSI is a horrific technology to use, but at least there is evidence that they seriously researched the problem space of complex software installation and attempted to address it. Apple’s installer is little more than a few bits wrapped around pax. Your final comment about sticking in a postflight script to set permissions….right, stunning example. An installer that can’t even get the permissions right without help from a custom script
Remind me again why would I want to use that technology?
Yes, third party installers can be annoying, but Apple’s really isn’t any better unless (a) you don’t require anything beyond copying files and (b) you have no needs to update or remove the software.
Now, why would an application need an installer? That is an excellent question and interesting debate, but unrelated to what makes a good installer when you do need one. The only thing more annoying than a sucky third party installer is a sucky third party installer that does nothing that could not be achieved with a single drag and drop off a DMG.
Oh, almost forgot, good luck with Apple’s installer if your target market isn’t covered by the 15 languages the installer is localized for.
Spot on Sketch. Id also like to add a couple trivial pet peeves about Software/Developers compared to what youve gone over here.
First, and i think this was covered in another article a while back,dont install your prefs and other user related info to some directory structure youve made up. It goes in ~/Library for user level and /Library for system/app level defaults. If you need some crazy structure beyond this initiate its root as a sub folder of one of these for the appropriate usage.
Secondly, and i may be alone on this, but PLEASE – no spaces in the names of ANY files/directories. I myself prefer Upper CamelCase but if thats not your thing then i can deal with underscores, periods, and dashes. I realize this doesnt cause the system any real problem but im not a big fan of escaping on quoting path strings.
Same here. We re-package all apps before deployment using DiffPackageMaker and Iceberg.
I managed to package Photoshop CS2 but I still need to activate the software on first launch. Has anyone found which extra file I need to install to prevent this ?
Regards,
Jp
Same here. We re-package all applications before deployment using DiffPackageMaker and Iceberg.
I managed to package Photoshop CS2, but I still need to activate the software on first launch. Does anyone know which file to add to my package to prevent this ?
thanks,
jp