As part of a recent task to build an AutoPkg recipe which creates an installer package for a screen saver, I ran into an issue. The vendor, for reasons that no doubt make sense to them, split the version information for the screen saver across two separate keys:

• Major part of the version number: Stored in the CFBundleShortVersionString key of the screen saver’s Info.plist file
• Minor part of the version number: Stored in the CFBundleVersion key of the screen saver’s Info.plist file

What this meant is that for version 1.4 of the screen saver, the version information was stored as follows:

• CFBundleShortVersionString key: 1
• CFBundleVersion key: 4

Getting this information was not the problem. AutoPkg includes a PlistReader processor which allows multiple values to be read from one plist file, so I used it as shown below to read the CFBundleShortVersionString key’s and the CFBundleVersion key’s values and store them in the following variables:

• CFBundleVersion key: minor_version
• CFBundleShortVersionString: major_version

So now I had the version info (in separate pieces) and now I needed to put them together. The problem I was seeing was that my usual solution, AutoPkg’s Versioner processor is set up to read one value from a plist file. I had two values and neither were in a plist file.

Fortunately, there are multiple ways to solve this problem. The first I thought of was to build a new plist as part of the recipe’s run and put the version information in. The workflow works like this:

1. Use the PlistReader processor to read the desired information.
2. Use the FileCreator processor processor to create a new plist file with the version information formatted as needed.
3. Use the PlistReader processor to read the version information out of the newly-created plist file.

This approach works, but now you have a plist file to clean up later. Another approach is to use custom variable assigning as part of another AutoPkg processor’s run. In this case, you’re using an AutoPkg processor and adding a separate argument which is probably unrelated to the other work the processor is doing, but does the value assignment work you couldn’t accomplish otherwise.

A pretty safe processor to use for this is the EndOfCheckPhase processor. The reason is that by itself, the EndOfCheckPhase processor takes no actions. Instead, it’s used as a marker in AutoPkg recipes to tell AutoPkg to stop checking for new information as part of a recipe’s run. However, even though the EndOfCheckPhase processor doesn’t take actions and doesn’t by default include Arguments values, AutoPkg will still process Arguments values if they’re defined for the EndOfCheckPhase processor. That allows custom variables to be set with values that you couldn’t otherwise set and pass them to AutoPkg. The workflow in this case looks like this:

1. Add the EndOfCheckPhase processor to the very end of the recipe.
2. Perform the desired variable assignment as an Arguments value

The reason to add it to the end is to make sure that all of the other tasks the recipe is performing are completed by the time this processor runs.

In this case, I used this method with the the EndOfCheckPhase processor in the screen saver’s .download recipe to assign the version variable to use the values of the major_version and minor_version variables, separated by a period.

The result for the latest version of the screen saver software is that the version variable is assigned the following value:

I’ve posted the recipes which use this technique for setting version information to GitHub. They’re available via the link below:

https://github.com/autopkg/rtrouton-recipes/tree/master/CarouselCloudScreenSaver