Question - is it possible to use any compression other that xar+gzip?

[mapron]

It's not a feature request yet, I could implement by myself. For example, if i compress bundle with LZMA, it gives me archive 31% less by size (which is significant). So is it possible? Does Apple enforces xar in any way?

[mapron]

I found #define XAR_OPT_VAL_GZIP "gzip" #define XAR_OPT_VAL_BZIP "bzip2" #define XAR_OPT_VAL_LZMA "lzma" defines in https://opensource.apple.com/source/xar/xar-36.2/xar/include/xar.h.in.auto.html Are they usable? can i change method in PKGArchive.m ?

[packagesdev]

IIRC, Apple uses lzma in the most recent distribution packages. I don't remember whether it's used for all the items within the xar archive or only for some (e.g. the payload or the resources).

The issue you could face is that decompressing lzma may not be supported on the macOS version you install the distribution/package. It would require to do some tests as I don't know which version of macOS started supporting it.

[mapron]

It strange, I tried to do xar-lzma on 10.14, and it seems not working:

$ xar -caf 1.xar Screenshot.png 
Error while creating archive:(Screenshot.png): lzma support not compiled in.

Looking at xar source code I hadn't noticed any defines for separate compressor/uncompressor.

bzip2 seems working anyway (we didn't do any thorough testing yet).

So, if you say it definetly should be fine (in terms of OS version supporting that option), it would be nice if some option would be in the future releases :) (--compression none|gzip|lzma|bzip)

[mapron]

Also, could you please provide link to official lzma compressed package?

[packagesdev]

As far as I know, the Payload is added as is to the xar archive. i.e. it's not compressed by the xar archiving process. I asked the person who told me about these lzma package and he listed the Kernel Debug Kit disk image as containing such packages.

You can also find more info here:

https://github.com/NiklasRosenstein/pbzx

[YesThatAllen]

I've read more on this lately, and have confirmed that a pkg I create in Packages is 47MB, but 31MB if I use pkgbuild, IF I use these options:

--min-os-version 10.10 --compression latest * * my package's is target 10.11, but Apple's compression kicks in at 10.10.

I learned this from Armin Breagle's blog here:

http://scriptingosx.com/2021/10/save-up-to-25-pkg-file-size-with-this-weird-monterey-trick/

(Incorrect attempts)

I've tried adding a few options in my .pkgproj:

<key>USER_DEFINED_SETTINGS</key>
<dict>
	<key>compression</key>
	<string>latest</string>
	<key>min-os-version</key>
	<string>10.11</string>
</dict>

as well as this under ADVANCED_OPTIONS

<key>installer-script.options:min-os-version</key>
<string>10.11</string>
<key>installer-script.options:compression</key>
<string>latest</string>

It seems as the settings and options are included in the result, instead of being used during the process.

I'm not sure if there's a way to "slipstream" these custom options.. I wonder if there are options to enhance the build process, other than features being added to Packages directly.

[mapron]

Thanks for the info, another 'pro' to go for pkgbuild directly :(

[YesThatAllen]

Ha! maybe, unless the option gets built in to Packages, which is my hope.

[YesThatAllen]

Until then.. munki-pkg worked to import & repackage what I built with Packages https://github.com/munki/munki-pkg/pull/60

[FunkyFr3sh]

Any updates on this?

[packagesdev]

Nope. This is still something on my to-do list and it would be very interesting to support it but I'm still not motivated, at the time of this writing, by the idea of having to give a hundred bucks to Apple to renew my developer membership subscription and install a recent version of macOS to investigate this; as it also means I would have to endure the sorry state of macOS UI/UX in Big Sur and later.