Closed YesThatAllen closed 10 months ago
Awesome. Can't wait to try this out.
So do!
It's always funny knowing what you'll say as I type things. :)
Also: do we know when these options were added to pkgbuild? If fairly recently we may want to check we're running under a recent-enough macOS version.
@scriptingosx sez the --compression
option was added in macOS 12.0 so I think we need to check for that as well. I don't need a bunch of support requests from admins trying to use these options on Big Sur or earlier. The code should guide them, not me :-)
I'm not gonna say I'm done, but at this point the tooling allows for min-os-version/compression without trying to enforce or auto-add the related keys.
I was looking at what it would take to auto-discover the settings in an existing package during --import
when I hit something interesting:
% ./munkipkg --import path/to/compressed.pkg newpkgtest
ditto: cpio read error: bad file format
ERROR: Ditto failed to expand Payload
and the newpkgtest
folder looks like
ls -al newpkgtest
total 65768
drwxr-xr-x 7 ahancock wheel 224 Apr 4 19:56 .
drwxr-xr-x 14 ahancock wheel 448 Apr 4 19:56 ..
-rw-r--r-- 1 ahancock wheel 1157317 Apr 4 19:56 Bom.txt
-rw-r--r-- 1 ahancock staff 1219 Apr 4 19:56 Distribution
-rw-r--r-- 1 ahancock staff 1076 Apr 4 19:56 PackageInfo
-rw-r--r-- 1 ahancock staff 31997300 Apr 4 19:55 Payload.cpio.gz
drwxr-xr-x 2 ahancock wheel 64 Apr 4 19:56 payload
Another part of this project might be to add support for decompressing the newer style of Payload.cpio.gz
. Maybe in a different issue/PR, but I wanted to at least stop & document where I was at.
The more I think about this, adding decoding of the newer cpio.gz feels like a separate issue (and of questionable priority)
Improvements to this PR which I can think of include:
--min-os-version
--min-os-version
(regex for 1*.*
?)--min-os-version
However, it's probably more than needed, and pkgbuild
will give appropriate scolding if the commands are used out of turn.
in other words, I think this PR is ready for more tire kicking/feedback.
I've got a need to reference this branch soon, bumping this PR to see if changes are needed, and if it can be merged. thanks!
Would be awesome to get this merged.
Similar to https://github.com/autopkg/autopkg/pull/905
I haven't invested much time into troubleshooting, but my baseline vms in my pkging pipeline is still on 12.x - this PR now throws:
pkgbuild: Inferring bundle components from contents of /Users/Shared/build/tmp_googlechrome.GaWXx7/googlechrome/payload
pkgbuild: Writing new component property list to /tmp/tmp5qu8ih9u/component.plist
munkipkg: Turning off bundle relocation for Applications/Google Chrome.app
Traceback (most recent call last):
File "/Users/Shared/resources/munki-pkg/munkipkg", line 1312, in <module>
main()
File "/Users/Shared/resources/munki-pkg/munkipkg", line 1308, in main
result = build(arguments[0], options)
File "/Users/Shared/resources/munki-pkg/munkipkg", line 917, in build
build_pkg(build_info, options)
File "/Users/Shared/resources/munki-pkg/munkipkg", line 620, in build_pkg
if build_info['compression']:
I assume this change now drops support for for macOS12.x - which is totally reasonable.
No, that looks like a bug to me.
I was creating a large pkg, and my go-to tooling doesn't support Apple's "new" compression options.
I read about "This one weird Monterrey trick" and added it to munki-pkg.
I am not sure that there would be differences in workflows by setting 10.5 & legacy, but this does change default behavior by adding two keys, even if not defined by the user. I set the defaults so as not to interrupt any workflows.
In my project file, I set them to min-os-version 10.10 and compression to latest, the resulting .pkg was 31MB vs 49MB.