When processing PackageInfo and Payload files, how can we best determine useful facts

[homebysix]

Here are the facts we need to gather from the PackageInfo and Payload files inside of an expanded flat package:

• bundle identifier
• install location
• Does it contain an app? If so, extract it and inspect_app().

This is not working 100% reliably at the moment.

And what if the payload contains multiple apps? Do we go with the one with the shortest path, as would be the case below?

$ gunzip -c /Users/elliot/Library/Caches/Recipe\ Robot/expanded/ChronoSync.pkg/Payload | p
ax | egrep "\.app$"
./Applications/ChronoSync.app
./Applications/ChronoSync.app/Contents/Library/LoginItems/ChronoSync Scheduler.app
./Library/Application Support/ChronoSync/ChronoAgentLocal.app

Or should we use the one with the largest file size? (How can we determine file size without extracting first?)

Or should we use the one with a Sparkle feed?

[sheagcraig]

I don't think going by size is a safe way of doing it.

I think there probably needs to be several tests applied:

• Where is the intended destination? With El Capitan, we're not allowed to install to /Applications/Utilities, so really, anything that doesn't go into /Applications would be suspect.
• Is there more than one .app in the path to the item in question? In the example above, I would think that ChronoSync Scheduler.app is clearly not the "main app" since it's, due to the multiple apps in its path, nested within another app (and further, nested inside the app that IS at a desirable location, and probably the one we've already flagged from the first test).
• I would hope that the main apps have a sparkle feed only. Helper apps shouldn't be prompting people for updates. Can you imagine if you got separate update notifications from the ChronoSync Scheduler right after you had updated ChronoSync? So I would think you get more points for having a sparkle feed; and if there's even more than one in a PackageInfo/Payload, assume something funky is going on.

[homebysix]

I've been staring at this block of code for a while trying to determine how to make it better. https://github.com/homebysix/recipe-robot/blob/master/scripts/recipe-robot#L1389-L1447

In short, it should:

• Take a look at the contents of the Payload file: gunzip -c Payload | pax
  • If it finds an app, make a note of it for future inclusion in blocking_applications (#39).
  • If the app is a standalone app (not nested within another like ChronoSync Scheduler.app above):
  • Extract the app by itself: gunzip -c Payload | pax -r -s \",./,/path/to/extract_dest/,\"
  • Run inspect_app() on the app. This will grab Sparkle feed, developer name, etc.

I'm OK with assuming the app will be installed to /Applications, although we do have the information we need to detect whether that's actually true (PackageInfo install-location plus the app's path within Payload).

Anybody want to take a crack at this? I've been looking at it for too long.

[sheagcraig]

I want to. I may not have a computer for the next week... But I'd like to.

[homebysix]

Three examples we can use for further education of the robot with regard to package files:

• http://www.macspeech.com/appcast/4.0/de/dictatede_DSA.xml
• https://dl.google.com/drive-file-stream/GoogleDriveFileStream.dmg
• https://www.meistertask.com/files/MeisterTask_osx.pkg

[homebysix]

I had some coffee and revisited this issue. I think I've got a good solution that should work most of the time.

• ditto -x for unpacking payloads instead of pax. Why didn't I learn about that sooner!?
• If a payload expands to a single app, easy. We inspect that app.
• If a payload expands to multiple apps, we use the biggest one.
• If a payload has no apps, that's firmly outside the scope of Recipe Robot.
• If a payload contains a .pkg bundle with a payload inside, grab the bundle identifier from the PackageInfo file and try to expand the payload.

There's still some loose wires around the generation of recipes after a lot of package-unpacking has taken place. For example, if we discover a signed app, we should switch CodeSignatureVerifier to use that. But the path may be variable depending on whether it's a pkg inside of a zip or dmg.

Latest changes on the better-pkg-handling branch.

[homebysix]

The changes discussed above (and others) have been incorporated into Recipe Robot 1.1.0+. Two of the three example URLs above are processed successfully by Recipe Robot now, and the other fails for an unrelated reason (404 error).