installhistory.plist

jarednichols
Honored Contributor

Since more an more installers are no longer dropping .pkg files into the Receipts folder and are instead entering info into InstallHistory.plist, how are folks handling these? Do you drop that from your Composer snap shot?

Thanks
j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

2 REPLIES 2

joelreid
New Contributor III

I hate to necro a post with no answer, but this is still not answered anywhere on the forums nor addressed in the documentation, for that matter.

There should proper documentation of the things that Composer and subsequent jamf installs may already handle intelligently; things like de-personalizing files from home folders, generalizing ByHost prefs, smart updating rather than overwriting of assorted files in-place, receipt creation, etc.

Is everyone just using Composer without grooming what's added, and just hoping for the best? Or winging it and learning the hard way what does or does not need culling? Why does everybody have to go through that? I'd settle for a FAQ somewhere on how to treat those myriad unexpected things that pop up in Composer... InstallHistory.plist, saved application states, CoreTypes.bundle, App Store/adoption.plist, /Library/Updates/, [later-dysfunctional] symlinks, logs, ~/Library/IdentityServices/, time machine prefs and files, Cookies.binarycookies, .DocumentRevisions-V100, unrelated-looking LaunchDaemons like fpsaud or cingen, /Users/Shared/adi, .spin files, unrelated-looking .localized files, and so forth.
With a sigh, jreid

donmontalvo
Esteemed Contributor III

This is why I cringe when I hear someone is creating PKGs via snapshots:

Is everyone just using Composer without grooming what's added, and just hoping for the best?

Snapshots only capture changes, which isn't always ideal. If an installer modifies a file, it's captured. If a new file is dependent on the UDID of the computer, it is also captured. Not even going to get into why pushing plist files is a bad idea (didn't understand why until a few months ago to be fair).

We use snapshots and FSEvents to see what's happening, if only to know how to approach a PKG task. Rarely do we ever actually use a snapshot for more than that (heck, we use Packages.app most of the time anyway).

Hopefully JSS 10 will make this all moot...

Will JSS 10 finally bring us easy patch management?
https://jamfnation.jamfsoftware.com/discussion.html?id=10961

Patch Management Integration <-- Status changed to PLANNED today!!!
https://jamfnation.jamfsoftware.com/featureRequest.html?id=662

Please make JSS track "package-id" and "version" in package receipts
https://jamfnation.jamfsoftware.com/featureRequest.html?id=2367

--
https://donmontalvo.com