autopkg/recipes

munkitools3.munki.recipe: munkitools_app_usage is not installed automatically

Closed this issue · 13 comments

flammable commented

In munkitools3.munki.recipe, the new munkitools_app_usage isn't an update_for, or set as requires by another package generated by the recipe. Because of this, deploying munkitools and/or munkitools_admin does not install munkitools_app_usage as well.

Would it be possible to set it to install before or after munkitools? Thanks!

Mike

timsutton commented

I wonder if the issue you're experiencing is somehow related to the way you've overridden the recipe? Not really sure how that'd be the case though, since thepkginfo is set explicitly in that processor step.

vmiller commented

I think Mike's point is that munkitools_app_usage will need to be listed explicitly in manifests.

timsutton commented

It shouldn't, because it being listed in requires would handle that. I've never listed it in my manifests and my test machines are getting it.

vmiller commented

I'm seeing that munkitools_app_usage requires core and launchd, but I'm not seeing munkitools_app_usage being required anywhere.

It is not getting deployed to my test machines. It is entirely possible that I am missing something obvious...

timsutton commented

Sorry, I clearly hadn't thought this through before responding.

Is there an argument for why it wouldn't be preferable to set app_usage as an update_for core only, similar to how munkitools_app works?

Since @MagerValp wrote the original recipe, he may be able to chime in on whether he'd intentionally made it an "opt-in" Munki component?

vmiller commented

Setting it as an update_for core makes sense to me.

flammable commented

Thanks, @timsutton and @vmiller! That makes sense to me, too. I also wanted to make sure that @gregneagle didn't consider it an optional pkg, like munkitools_admin (which must be explicitly added to a manifest).

gregneagle commented

I do consider it an optional package. That is why it is its own pkg.

timsutton commented

I thought that might be the idea, too. Although unless I'm missing something (again), munkitools_admin is set as an update_for core. I'll update the Description for this recipe to the effect of munkitools_app_usage being optional in the hopes of clarifying this for others.

timsutton commented

Proposing this as a change to Description:

Note: munkitools does not include a code signature. If your
organization requires code signature, it is recommend to internally sign
the application.

Downloads and imports version 3 of the Munki tools via
the official releases listing on GitHub. While Munki 3 is in prerelease,
this recipe sets INCLUDE_PRERELEASES, and this will set to off by default
when there is an official release.

Note that Munki 3 includes an additional component pkg, munkitools_app_usage.
This recipe imports this to the Munki with the appropriate 'requires' key,
however as it is considered an optional component, this recipe does not
add it as an update_for any Munki component. Admins should add
munkitools_app_usage to a manifest manually if its installation on clients
is desired.

This recipe cannot be overridden to pull a download from an
alternate location such as munkibuilds.org - it will only download the
official releases. For this, use the munkitools2-autobuild.munki
recipe with a manually-provided DOWNLOAD_URL variable.

The GitHubReleasesInfoProvider processor used by this recipe also
respects an input variable: 'sort_by_highest_tag_names', which
if set, will ignore the post dates of the releases and instead sort
descending by tag names according to LooseVersion semantics.

MUNKI_ICON should be overridden with your icon name.

Yay/nay?

flammable commented

Cool, looks good to me! Maybe the line referencing munkitools2-autobuild.munki could be updated when there's a munkitools3-autobuild.munki.

Thanks guys!

vmiller commented

That description looks good to me.