When processing PackageInfo and Payload files, how can we best determine useful facts about recipe-robot HOT 6 CLOSED

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.

from recipe-robot.

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.

from recipe-robot.

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

from recipe-robot.

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

from recipe-robot.

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.

from recipe-robot.

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).

from recipe-robot.