Using the Packages installer builder for Apple Silicon / M1 distributions?

Quick question for people also using the Packages installer builder to deploy their software apps/plugins on macOS: I currently have a CPU architecture check set to “Intel” in my Packages installer setup. Apparently, there are only Any, PowerPC or Intel as options at the moment.

Did anyone figure out if/how we can somehow get M1/ARM/Apple Silicon in there too?

This is the problem with using Packages.

I think probably given the amount of time passed that the developer isn’t interested in adding this support (perhaps doesn’t have an M1 machine to test with, and it’s not like they’re making any money from Packages to fund one).

My advice : spend a day learning how to use pkgbuild which Packages is more or less a glorified wrapper for, although something like this platform checking might be easier said than done that way, since the documentation for it is quite sparse and hence rather annoying. A good starting point for learning pkgbuild by example is the Surge repo.

3 Likes

I’d recommend the same, but it’s really not so well documented. To make a proper installer you need both pkgbuild and productbuild. The former lets you build the basic install packages for the different plugin formats (for example), and the latter glues them together into a proper installer that you can configure to your liking.

The distribution.xml reference comes in handy to figure out how to configure the installer.

The cool thing is that you can fully automate that stuff. I’ve implemented it in CMake and managed to build a nice-ish dist.xml using a jinja template.

2 Likes

Is there a reason now not to put Any ?

Yes, I was exactly thinking that too now: no one is running a PowerPC any longer I suppose :wink:

The only thing I wasn’t sure of was this:
Would not requiring Intel perhaps turn off the necessity to install/enable Rosetta (in case not all products in the installer support ARM yet)? But I’m not sure any more when exactly the system finds out that Rosetta is required. It might very well happen only when you actually run an Intel binary, and then it should still be fine.

imho you re fine leaving Any.

Yes, I actually just removed the CPU check altogether: the number of cores / minimum CPU freq. didn’t make much sense anyway and since I’m already requiring macOS 10.9 or above now, there’s also no chance of running into a PowerPC or 32-bit processor.

1 Like

Since you don’t need this processor check I’d reiterate the advice about learning the underlying tools so you can dump the Packages dependency. Use the Surge repo (I helped with the installer stuff initially and learned a load of extra stuff from changes @baconpaul did), and if you have any other questions would be happy to help via PM. :slight_smile:

2 Likes

Just a last follow-up as I have received an answer from Stéphane, the author of Packages.

He also says just using “Any” could be a solution for now, but apparently, you can also enable Advanced User Options and then you can actually type in the host architectures as you wish:

“Any” could be a good solution with the 1.2.9 release of Packages. You may also need to set the hostArchitectures option to i386 arm64.

(in his current intermediate development build, this is being calculated automatically if you want to use the Intel + Apple Silicon combo)

3 Likes

Sort of related, so I may as well ask here as I’ve been wondering about it but not looked into this yet - as the installers I’ve come across identify as Intel binaries and run through Rosetta, do we need to start moving to an installer build process that can generate universal binary installers? Presumably Rosetta will be removed one day and we’d loose the ability to run such installers. Do we have a path out of this? Maybe the command line tools already take care of that, I don’t know, I only use Packages too. Has Stéphane addressed this at all or does anybody know where we’re going on that?

This is important. Otherwise, the installer wants to install Rosetta2 on M1 machines that haven’t Rosetta2 installed.

1 Like

See here (You need to set the hostArchitectures option to i386 arm64):

3 Likes

Just a quick follow-up/confirmation question:

So, if I got this right, adding arm64 as specified means:

  1. that running the built installer on an Intel machine will just install the Universal Binary files in the package?
  2. that running the built installer on an ARM-based Mac will not ask to install Rosetta, and run as an ARM application natively (so the installer itself is also a Universal Binary)?

Also: what would you do if your installer contains UB versions of VST and AU plugins + Intel only version of AAX plugin? (because for the AAX, you really need to have Rosetta2 in order to run it)

Edit: Actually, I am building UB AAX versions too, but Pro Tools is still Intel only, so perhaps I just shouldn’t care, and add that arm64 flag in any case, because Rosetta2 will already be installed for Pro Tools anyway?

OK, from the productbuild man page, it looks like if you’re building the installer on Big Sure or upwards, support for both arm64 and x86_64 should automatically be added now (but apparently not for macOS versions below Big Sur):

Since I’m building on Big Sur, I’ll just leave that setting empty then.

You have to try this. I’m not sure if this is set automatically if you are using packages to create the installer on BigSur.
The installer does not verify if you have only UB2 files. I also have intel AAX plugins included.

You can verify on M1 when you open the activity monitor and it shows APPLE in the processor column of the installer process.

Thanks!

I did some actual tests this afternoon (on an M1 cloud machine at Scaleway), and can share my experiences:

If I don’t make that “host architectures” setting change, I still get the warning that Rosetta needs to be installed, even when building the package on Big Sur:

Rosetta warning

When I look in at the Installer properties at that point (when that install dialog is shown), I can see that the “Kind” is “Apple”:

I then re-tried with “x86_64 arm64” (and “x86_64, arm64”) and that works fine then: you don’t get the warning about Rosetta.

In both cases (without the set “Host architectures” option and with the option), the installer showed up with “Kind” being “Apple” (so also in the case where the Rosetta warning popped up).

Packages were built on Big Sure 11.6.1 using Packages 1.2.9 (599), and deployed to a Mac mini (M1, 2020) running Big Sure 11.3.1 (running in the Scaleway cloud).

Conclusion
I do need to have that option set explicitly apparently, if I want to avoid seeing that Rosetta install dialog.

4 Likes

Somehow related to the topic, a tool I found useful is Suspicious Package, which tells you right away in the first window if the .pkg being examined will require installation of Rosetta2 or not (among all the other useful things)

3 Likes