PackageRequired is a processor that has no arguments. Regardless of your reason, the -pkg option works well in this case, in partnership with the PackageRequired processor.
Sometimes, you can automate a download, but the product is updated so infrequently, it’s not worth the effort.
BLOCKBLOCK AUTOPKG RECIPE HOW TO
Common reasons are: the vendor requires that you provide login credentials to obtain the software, there are too many redirects by the web site for AutoPkg to handle, the site’s Terms of Service do not allow automated downloads, and the recipe author (probably you) hasn’t figured out how to automate the download but still wants to use the other features of AutoPkg (like building a package installer or putting the software into your distribution system). Sometimes, you just can’t automate a particular download.
BLOCKBLOCK AUTOPKG RECIPE VERIFICATION
If I’ve downloaded the latest version of MuseScore to my Downloads folder, and I want to run the pkg recipe for it, I would use the following command:Īutopkg run MuseScore.pkg -pkg ~/Downloads/MuseScore-2.3.2.dmgĪutoPkg will follow all the steps of the recipe, including code signature verification and possibly building a package, but when it gets to the URLDownloader processor, it will skip downloading and will return values as if the item specified by -pkg was just downloaded as a new item. For example, MuseScore is provided as an app wrapped in a disk image. Whatever the reason, you can manually download the item in the format that the recipe would normally expect (e.g., dmg, pkg, zip) and specify that path with the -pkg option. Or perhaps you have been provided with a beta version to help fix a bug and you would like to get that out to your testing group using the recipes that feed your software distribution system (e.g., Munki). For example, there might be a new version available for download on their web site but their Sparkle feed hasn’t been updated yet, and the AutoPkg recipe uses the Sparkle feed to determine the current version. When the vendor uses more than one mechanism to make new software available, sometimes these are not updated simultaneously. “Why hasn’t AutoPkg found the latest version? I can see it on the vendor’s web site!” This is probably the most common usage of the -pkg option-it’s even described in the AutoPkg FAQ. Let’s address each one of these in order. You are developing a recipe and do not wish to redundantly download the software during testing.You can’t automate the download of the software or haven’t yet done the work to make that happen and.You have access to a version of the software that is newer than the related AutoPkg recipe knows about.There are three main reasons to use the -pkg option when running an AutoPkg recipe: You may only use this option when running a single recipe (not a list or multiple recipes). UsageĪutopkg run -pkg /path/to/pkg_dmg_or_archive recipename.recipetypeĪutopkg run recipename.recipetype -pkg /path/to/pkg_dmg_or_archive If your recipe chain doesn’t use URLDownloader, your recipe can still access the path to the download using variable substitution (i.e.
it sets the output variable download_changed to True).
URLDownloader will treat the supplied item as an updated version (i.e. The -pkg option allows you to direct AutoPkg to use a package or disk image that you have on hand (which you probably manually downloaded) instead of downloading whatever the URLDownloader processor in your recipe would normally retrieve. This post is the missing documentation for that option. Yet that option that can be very useful for recipe authors and users alike. AutoPkg offers an option when you run a recipe from the command line that is mentioned exactly once in the Wiki: the -pkg (or -p) option.
0 kommentar(er)
