[benfeea1]

Bump —

Come on. I cannot be the Mac admin who wants to do this.

[benfeea1]

Think about a payload free package used to uninstall something.
You would use a post-flight script to rm all the files and directories associated with the software.
In the end you really would not want or need a receipt for the uninstaller pkg hanging around..

This question is not really about InstaDMG or image deployment per say. It is more of a package creation question. But I know all the packaging expertise is found in this forum.

[benfeea1]

I agree. pkgutil –forget com.myorg.somepackage is the way to go.
However, it does not work from a postflight script, because the receipt has not been written yet.
Chicken and the egg.

[benfeea1]

The real question is will there be a Thirsty Bear AFP548 WWDC party?
That is the real reason I attend WWDC.

Eric

[benfeea1]

Inconclusive results for far.
The new InstallerChoices.xls is technically working so far, but I still have some issues. I feel like I have only peeled away one layer of this onion.

More info to come.

[benfeea1]

You must be running 10.6.x to use instaDMG to build a 10.6 image.

[benfeea1]

Spider,

“you could install it to the User Template folder, but not recommended”

This may need to be a new topic, but what is the recommend alternative to modifying the User Template folder?

[benfeea1]

larkost,

You are a very wise Marklar. That worked perfectly.

#!/bin/bash
# postflight script
# Installer.app Environmental Positional Variables.
# $0 Script path
# $1 Package path
# $2 Default location
# $3 Target volume
# Declare the Enviromental Positional Variables so the can be used in function calls.
ScriptPath=$0
PackagePath=$1
DefaultLocation=$2
TargetVolume=$3
PackageName=$( /usr/bin/basename “$PackagePath” )

RemovePackageReceipt () {
rm -rf “${TargetVolume}/Library/Receipts/${PackageName}”
echo removed “${TargetVolume}/Library/Receipts/${PackageName}”
}

RemovePackageReceipt

[benfeea1]

Check out CrashPlan. [url]www.crashplan.com[/url]
I am backing up 750 systems to two separate destinations.

[benfeea1]

One Button.
Endless possibilities.

[benfeea1]

I use this bit of code.

hardwaretype=`/usr/sbin/system_profiler SPHardwareDataType | grep Model`
if echo $hardwaretype | grep -i Book;
then
echo This is a Mac Portable
else
echo this is NOT a Mac Portable
fi

[benfeea1]

Yeah, I was planning on a separate build until 10.5.6.

[benfeea1]

As a wise man once said, “What changed before nothing changed?”
What packages did you add to your build train? I bet you added a new custom package, or one of Apple’s updates recently.

I have several build trains. The most important one is the base build train. This train ONLY has the Apple updates, and a few select custom packages.
I put packages in the base build train to test them first.

[benfeea1]

“This release of J2SE 5.0 and J2SE 1.4.2 supports all Intel and PowerPC-based Macs. Java SE 6 is available on 64-bit, Intel-based Macs only.”

I was thinking that if I build on an Intel Mac, this would end up installing “Java SE 6” which is not necessarily supported by non-64-bit or non-Intel-based Macs. Would that be bad?

[benfeea1]

I still prefer Iceberg. I have a template already setup in Iceberg with my logos and scripts.
I use Composer to gather the files / do the delta. Composer is very efficient at gathering all the correct components of an install. I don’t mind paying 99.00 to save my sanity.

[Author]

Posts