一般的にコレを使うのかはよくわからない
でも今後のmacOSでは認証済み.pkgしか入れられない状況になるかもしれないって考えると知ってて損はない・・・？
ココとココで散々.pkgファイルを触る機会があったので乗りこなしてやろうかと軽い気持ちで調べてみたら思った以上に分量があって，もうなんだかタイムスリップした気分に・・・
仕様がどんどん複雑化していってるというリプをいただいたので，果たしてコレが事実を掠められてるかすら怪しい，もうBig Surになってからでいいんじゃないかなぁ・・・
先行参考リンク
Mac用Installerの作り方
- 2020/04/07
- @ioue さん
Mac OSX Sierra上でアプリケーションをAgentとしてインストールする方法
- 2018/01/12
- @birdland007s さん
MacOSXパッケージ関連コマンドまとめ
- 2016/05/05
- @virusVer001 さん
Macインストーラーの作成方法
- Qiita外の記事です
- 2015？
Macでインストールしたパッケージを削除する
- 2014/11/13
- @ysk24ok さん
productbuildによるインストーラ作成
- Qiita外の記事です
- 2013/10/29
- kimuraw さん
Mac OS Xのパッケージ管理
- Qiita外の記事です
- 2013/08/18
- @lufia さん・・・かな・・・？(プロフ画が同じだった)
pkgbuildとproductbuildでMacのインストーラーを作ろう
- Qiita外の記事です
- 2013/03/12
- mas さん
Mac OS Xのパッケージファイルを操作する
- Qiita外の記事です
- 2012/01/29
- niw さん
ツールをman
※以下は読みやすいようにインデントや改行等を整形した
man pkgutil
pkgutil(1) BSD General Commands Manual pkgutil(1)
NAME
pkgutil -- Query and manipulate Mac OS X Installer packages and receipts.
SYNOPSIS
pkgutil [options] [commands]
DESCRIPTION
pkgutil reads and manipulates Mac OS X Installer flat packages, and provides access to the ``receipt'' database used by the Installer.
Options are processed first, and affect the operation of all commands.
Multiple commands are performed sequentially in the given order.
The files and directories where receipts are stored are subject to change.
Always use pkgutil to query or modify them.
OPTIONS
--help, -h A brief summary of commands and usage.
--force, -f
Don't ask for confirmation before performing a potentially destructive or ambiguous operation.
--verbose, -v
Output in a "human-readable" format with extra headers, footers, indentation, and other contextual information.
--volume path
Perform all operations on the specified volume or home directory.
The root volume '/' will be used if unspecified.
--edit-pkg package-id
Specifies an existing receipt to be modified in-place by --learn.
--only-files
List only files (not directories) in --files listing.
--only-dirs
List only directories (not files) in --files listing.
--regexp
Try to match package-id arguments as a regular expression if an exact match isn't found.
See egrep(1) and re_format(7) for syntax.
RECEIPT DATABASE COMMANDS
--packages, --pkgs
List all installed package IDs on the specified --volume.
--pkgs-plist
List all installed package IDs on the specified --volume in Mac OS X plist(5) format.
--pkgs=REGEXP
List all installed package IDs matching REGEXP on the specified --volume.
The equal sign (=) is required or the search string will be ignored and all package IDs will be returned.
Be mindful of escaping characters in both your shell and the regular expression.
(Eg, 'pkgutil --pkgs=\\.D' searches for package IDs matching the literal '.D' after escaping the backslash from your shell and then the dot from the regex to make it literal.)
Regular expressions are more complex than simple shell globbing.
A dot (.) matches any character, while '*' matches zero or more of the previous character.
See re_format(7) for a complete description of the syntax.
--files package-id
List all of the files installed under the package-id.
--export-plist package-id
Print all receipt information about the specified package-id in the standard Mac OS X plist(5) format.
--pkg-info package-id
Print extended information about the specified package-id.
--pkg-info-plist package-id
Print extended information about the specified package-id in Mac OS X plist(5) format.
--forget package-id
Discard all receipt data about package-id, but do not touch the installed files.
DO NOT use this command from an installer package script to fix broken package design.
--learn path
Update the ACLs of the given path in the receipt identified by --edit-pkg.
This affects subsequent repair operations on the package. This command cannot be used from package postinstall scripts, but if a postinstall script changes the ACLs on the installed files, the receipt is automatically be updated to reflect those changes.
This command will not update the filesystem permissions in the receipt.
--pkg-groups package-id
List all of the package groups this package-id is a member of.
--groups List all of the package groups on the specified --volume.
--groups-plist
List all of the package groups on the specified --volume in Mac OS X plist(5) format.
--group-pkgs group-id
List all of the packages that are members of this group-id.
--file-info path
Show the metadata known about path.
--file-info-plist path
Show the metadata known about path in Mac OS X plist(5) format.
FILE COMMANDS
--expand pkg-path dir-path
Expand the flat package at pkg-path into a new directory specified by dir-path.
--flatten dir-path pkg-path
Flatten the dir-path into a new flat package created at pkg-path.
The directory to be flattened must have the proper contents and layout for a flat package.
This is not intended as a substitute for pkgbuild(1).
--bom path
Extract any BOM files from the flat pkg at path into /tmp and return the filename(s).
Suggested use is as an argument to lsbom(8).
Eg, "lsbom `pkgutil --bom path`".
Note that some flat package archives may contain no BOM, one BOM, or several BOMs.
--payload-files path
List the files archived within the payload of the uninstalled flat package(s) contained at path.
This should be equivalent to "lsbom -s `pkgutil --bom path`".
Note that flat package archives may contain more than one package, and the destination location for the uninstalled package(s) is unknown to this command.
--check-signature pkg-path
Check the validity and trust of the signature on the package at pkg-path.
In addition to the status of the signature, the associated certificate chain will be shown.
SEE ALSO
installer(8)
pkgbuild(1)
productbuild(1)
Mac OS March 2, 2011 Mac OS
man installer
INSTALLER(8) BSD System Manager's Manual INSTALLER(8)
NAME
installer -- system software and package installer tool.
SYNOPSIS
installer [-dominfo] [-volinfo] [-pkginfo] [-showChoicesXML] [-showChoicesAfterApplyingChangesXML <pathToXMLFile>] [-applyChoiceChangesXML <pathToXMLFile>] [-query <flag>] [-allow] [-dumplog] [-help] [-verbose | -verboseR] [-vers] [-config] [-plist] [-file <pathToFile>] [-lang <ISOLanguageCode>] [-listiso] -pkg <pathToPackage> -target device
DESCRIPTION
The installer command is used to install macOS installer packages to a specified domain or volume.
The installer command installs a single package per invocation, which is specified with the -package parameter ( -pkg is accepted as a synonym).
It may be either a single package or a metapackage.
In the case of the metapackage, the packages which are part of the default install will be installed unless disqualified by a package's check tool(s).
The target volume is specified with the -target parameter ( -tgt is accepted as a synonym).
It must already be mounted when the installer command is invoked.
The installer command requires root privileges to run.
If a package requires authentication (set in a package's .info file) the installer must be either run as root or with the sudo(8) command (but see further discussion under the -store option).
The installer is not responsible for rebooting the machine after installing.
Use reboot(8) or shutdown(8) -r now to reboot the system.
The installer displays two forms of output.
The default terse output is intended for parsing by scripting languages for automating (or scripting) installs and verbose output providing additional information and descriptive error messages.
A list of flags and their descriptions:
-dominfo
Displays a list of domains into which the software package can be installed.
For example: LocalSystem or CurrentUserHomeDirectory.
The domains listed are those which are available and enabled when the command is run.
-volinfo
Displays a list of volumes onto which the software package can be installed.
The volumes listed are the mounted volumes available when the command is run.
-pkginfo
Displays a list of packages that can be installed onto the target volume.
If a metapackage is given as the package source, all of its subpackages are listed.
-query flag
Queries a package for information about the metadata.
See -help for supported flags.
-allowUntrusted
Allow install of a package signed by an untrusted (or expired) certificate.
-dumplog
Detailed log information is always sent to syslog using the LOG_INSTALL facility (and will wind up in /var/log/install.log).
-dumplog additionally writes this log to standard error output.
-help
Displays the help screen describing the list of parameters.
-verbose
Displays more descriptive information than the default output.
Use this parameter in conjunction with -pkginfo and -volinfo information requests to see more readable output.
The default output is formatted for scripting.
-verboseR
Displays same information as -verbose except the output is formatted for easy parsing.
-vers
Displays the version of this command.
-config
Formats the command line installation arguments for later use.
The output is sent to stdout, but can be redirected to a file to create a configuration file.
When specifying this option, an installation is not actually performed.
This configuration file can be supplied as the argument to the -file parameter instead of typing a long series of installation arguments.
The config file can be used to perform multiple identical installs.
You can create a config file as follows:
installer -pkg ~/Documents/Foo.pkg -target / -config > /tmp/configfile.plist
-plist
Formats the installer output into an XML file, which is sent by default to stdout.
Use this parameter for -dominfo, -volinfo, and -pkginfo
-file pathToFile
Specifies the path to the XML file containing parameter information in the key/value dictionary.
This file can be used instead of the command line parameters, and supersedes any parameters on the command line.
When you type this parameter, you type the path to the XML file.
Use with config file generated by -config For example:
installer -file /tmp/configfile.plist
-lang ISOLanguageCode
Default language of installed system (ISO format).
This is only necessary when performing a system (OS) install, otherwise is it ignored.
There is no verification done to make sure that the language being set actually exists on the machine, however the ISO language code is verified to ensure that it is valid.
-listiso
Display the list of valid ISO language codes the installer recognizes.
-showChoiceChangesXML
Prints to stdout the install choices for the package (specified with -pkg) in an XML format.
This allows choice attributes to be modified and applied at install-time using -applyChoiceChangesXML.
See CHOICE CHANGES FILE for details of this XML format.
-applyChoiceChangesXML pathToXMLFile
Applies the install choice changes specified in pathToXMLFile to the default choices in the package before installation.
This allows the command-line installer to customize choice what gets installed.
See CHOICE CHANGES FILE for details of this XML format.
Any problems encountered while applying the choice changes will be reported to the LOG_INSTALL facility (i.e. to /var/log/install.log), and also to stdout if -dumplog is used.
-showChoicesAfterApplyingChangesXML pathToXMLFile
Applies the install choice changes specified in pathToXMLFile to the default choices in the package, and then dumps the resulting choice state to stdout.
The input and output XML format is as described in CHOICE CHANGES FILE.
Since changing one choice in a package can implicitly change other choices, this option allows you to confirm that a particular choiceChanges file will have the intended effect.
You must specify a -target when using this option, since the evaluated choices can also change with the state of the target disk.
-showChoicesXML
Prints to stdout the install choices for the package (specified with -pkg) in a hierarchical XML format.
This is not the same format as used with -applyChoiceChangesXML.
This option is provided for System Image Utility only.
-store
Install the product archive specified by -package, in the same way that it would be installed through the Mac App Store.
In this mode, no other options are supported. (You can specify -target, but the only allowable value is the root volume mount point, /).
For best Mac App Store fidelity, run installer as an admin user (not using sudo); you will prompted for your admin user's password before the install begins.
This mode is provided for testing a product archive before submission to the Mac App Store.
See productbuild(1) for how to create a product archive.
DEVICES
A device parameter for the target is any one of the following:
1)
Any of the values returned by -dominfo
2)
The device node entry. Any entry of the form of /dev/disk*. ex: /dev/disk2
3)
The disk identifier. Any entry of the form of disk*. ex: disk1s9
4)
The volume mount point. Any entry of the form of /Volumes/Mountpoint.
ex: /Volumes/Untitled
5)
The volume UUID. ex: 376C4046-083E-334F-AF08-62FAFBC4E352
CHOICE CHANGES FILE
A ``choiceChanges'' file allows individual installer choices to be selected or deselected.
A template choiceChanges file for a given package can be generated with the -showChoiceChangesXML option, and is interpreted as follows.
The choiceChanges file is a property list containing an array of dictionaries.
Each dictionary has the following three keys:
Key
Description
choiceIdentifier
Identifier for the choice to be modified (string)
choiceAttribute
One of the attribute names described below (string)
attributeSetting
A setting that depends on the choiceAttribute, described below (number or string)
The choiceAttribute and attributeSetting values are as follows:
choiceAttribute
attributeSetting Description
selected
(number) 1 to select the choice, 0 to deselect it
enabled
(number) 1 to enable the choice, 0 to disable it
visible
(number) 1 to show the choice, 0 to hide it
customLocation
(string) path at which to install the choice (see below)
Note that there can be multiple dictionaries for the same choiceIdentifier, since there can be multiple attributes set for a single choice.
The customLocation attribute can be set for a choice only if that choice explicitly allows a user-defined path.
That is, if the choice would have a Location popup when viewed in the Customize pane of the Installer application, it can be set via customLocation.
(Otherwise, installation paths cannot be arbitrarily modified, since the package author must account for custom install locations for the installation to work properly.)
EXAMPLES
installer -dominfo -pkg InstallMe.pkg
installer -volinfo -pkg InstallMe.pkg
installer -pkginfo -pkg DeveloperTools.mpkg
installer -pkg OSInstall.mpkg -target LocalSystem
installer -pkg OSInstall.mpkg -target / -lang en
installer -pkg DeveloperTools.mpkg -target /
installer -pkg InstallMe.pkg -target "/Volumes/Macintosh HD2"
installer -pkg InstallMe.pkg -file /tmp/InstallConfigFile
installer -pkg InstallMe.pkg -target /dev/disk0s5
ENVIRONMENT
COMMAND_LINE_INSTALL
Set when performing an installation using the installer command.
FILES
/usr/sbin/installer
Software package installer tool
SEE ALSO
syslog.conf(5)
reboot(8)
shutdown(8)
softwareupdate(8)
sudo(8)
systemsetup(8)
HISTORY
The command line installer tool first appeared in the 10.2 release of Mac OS X.
macOS April 19, 2007 macOS
man productbuild(これいる？)
productbuild(1) BSD General Commands Manual productbuild(1)
NAME
productbuild -- Build a product archive for the OS X Installer or the Mac App Store
SYNOPSIS
productbuild [--product requirements-plist] {--component component-path [install-path]} product-output-path
productbuild {--content content-path} product-output-path
productbuild [--product requirements-plist] {--root root-path install-path} product-output-path
productbuild [options] --distribution dist-path [--package-path search-path] product-output-path
productbuild --synthesize [--product requirements-plist] {--package pkg-path} distribution-output-path
DESCRIPTION
A product archive is a flat file with a .pkg extension.
productbuild creates a deployable product archive, which can be used with the OS X Installer, or submitted to the Mac App Store.
It has 5 different modes, as shown in the SYNOPSIS above:
1.
Create a product archive from a bundle (e.g. for the Mac App Store).
If you have a self-contained bundle (e.g. an app) that always gets installed to the same location (e.g. /Applications), specify the bundle and install path using the --component option.
You can specify additional requirements using a PRE-INSTALL REQUIREMENTS PROPERTY LIST.
When you specify a bundle, productbuild automatically creates a component package, much like pkgbuild(1), and synthesizes a distribution file.
2.
Create a product archive for in-app content.
Specify in-app content using the --content option.
3.
Create a product archive from a destination root.
When you use xcodebuild(1) with the install action, the result is a destination root, either under /tmp, or in whatever location you specify with the Xcode DSTROOT setting.
Use the productbuild --root option to specify that destination root directory and its install path.
You can specify additional requirements using a PRE-INSTALL REQUIREMENTS PROPERTY LIST.
When you specify a root, productbuild automatically creates a component package, much like pkgbuild(1), and synthesizes a distribution file.
4.
Create a product archive using a distribution file.
If you have a distribution file, use the --distribution option to specify the path to it, and the --package-path option to specify the directory where the component packages are found (if they are not in the current working directory).
All packages referenced by the distribution will be incorporated into the resulting product archive.
5.
Synthesize a distribution for one or more component packages.
This also synthesizes a distribution (also using an optional PRE-INSTALL REQUIREMENTS PROPERTY LIST), but writes out the resulting distribution instead of incorporating it into a product archive.
This can serve as a starting point if a more sophisticated distribution is required.
When creating product archives for submission to the Mac App Store, use only the --component mode of productbuild.
The other modes will create product archives that are compatible with the OS X Installer, but are not necessarily acceptable for the Mac App Store.
ARGUMENTS AND OPTIONS
--distribution dist-path
Use the distribution file at dist-path to define the presentation, choices and packages to be installed by the product.
Each of the package names referenced in the given distribution file must be found in a path specified with the --package-path flag.
If --distribution is omitted, a distribution will be synthesized to install all of the bundles given by --component flags, or all of the packages given by --package flags.
--package-path search-path
productbuild will search in search-path for component packages named in the distribution.
You can use multiple --package-path flags if necessary.
The current working directory is searched automatically.
--resources rsrc-dir
productbuild will copy the resources from rsrc-dir into the resulting product archive.
rsrc-dir can contain unlocalized resources (such as image files) and/or standard lproj directories (e.g. English.lproj) containing localized resources (such as strings files).
--ui interface-type
If the distribution has multiple choices-outline elements, you can use --ui to select one for building the product archive: this controls which package references are used.
The interface-type should match the value of the ``ui'' attribute on the desired choices-outline.
The default is to use the choices-outline with no ui attribute.
If used without --distribution, the given interface-type will be used for the choices-outline of the synthesized distribution.
--identifier product-identifier
The given unique (non-localized) product-identifier will be associated with the product.
--version product-version
The given product-version string will be associated with the product.
--component component-path [install-path]
The bundle at component-path is added to the product archive (as its own component package) and to the synthesized distribution.
If install-path is specified, it is used as the default install location for the bundle.
(If you omit install-path, a location is inferred from the given component-path.)
Valid only if --distribution is not specified.
--component-compression compression-mode
Allows control of compression used for storing any components added via the --component option.
This option does not affect the compression used for plugins or scripts. Three compression-mode arguments are supported:
o
legacy forces a 10.5-compatible compression algorithm for all components.
o
auto enables productbuild to automatically select newer, more efficient compression algorithms based on properties of the component, such as supported operating system versions.
(See os in the PRE-INSTALL REQUIREMENTS PROPERTY LIST section for more details on specifying operating system requirements.)
o
default provides identical behavior to omitting --component-compression entirely.
It is currently equivalent to legacy but may change in future releases of OS X.
Note that the Mac App Store may override the specified compression-mode for submitted product archives.
Valid with --component only.
To control compression of component packages with --distribution or --root use pkgbuild(1) and reference each component package in a distribution file.
--content content-path
The contents of the directory at content-path are added to the product archive (as its own component package) and to the synthesized distribution.
Valid only if --distribution is not specified.
--root root-path install-path
The entire directory tree at root-path is added to the product archive (as its own component package) and to the synthesized distribution.
This is typically used for a destination root created by xcodebuild(1).
Valid only if --distribution is not specified.
--package pkg-path [install-path]
The component package at pkg-path is added to the product archive and to the synthesized distribution.
If install-path is specified, it is used as the default install location for the package, overriding any default location specified by the component package itself.
Valid only if --distribution is not specified.
--synthesize
Write the synthesized distribution directly instead of incorporating it into a product archive.
--product requirements-plist
When synthesizing a distribution, use the requirements from requirements-plist.
See PRE-INSTALL REQUIREMENTS PROPERTY LIST (this was formerly called the "product definition property list").
--scripts scripts-path
The contents of scripts-path is added to the product archive for use by system.run() commands in the distribution.
This is valid only for product archives targeted to the OS X Installer application.
--plugins plugins-path
The contents of plugins-path is added to the product archive for use by the OS X Installer application's plugin mechanism.
It will normally contain a InstallerSections.plist file, and one or more plugin bundles.
--sign identity-name
Adds a digital signature to the resulting package.
See SIGNED PRODUCT ARCHIVES
--keychain keychain-path
Specify a specific keychain to search for the signing identity.
See SIGNED PRODUCT ARCHIVES
--cert certificate-name
Specify an intermediate certificate to be embedded in the package.
See SIGNED PRODUCT ARCHIVES
--timestamp
Include a trusted timestamp with the signature.
See SIGNED PRODUCT ARCHIVES
--timestamp=none
Disable trusted timestamp, regardless of identity.
See SIGNED PRODUCT ARCHIVES
--quiet
Inhibits status messages on stdout.
Any error messages are still sent to stderr.
product-output-path
The path to which the product archive will be written.
distribution-output-path
When --synthesize is used, the path to which the synthesized distribution will be written.
PRE-INSTALL REQUIREMENTS PROPERTY LIST
When you use productbuild to synthesize a distribution (e.g. with the --component option), you can specify pre-install requirements in a separate property list file, specified with the --product option.
(When you use Xcode to create a package for the Mac App Store, you can specify this file using the "Pre-install Requirements Property List" build setting.)
At the top level, this property list is a dictionary, with the following keys:
Key
Description
os
Minimum allowable OS versions (array of strings)
arch
Supported architectures (array of strings)
ram
Minimum required RAM in gigabytes (real)
bundle
Specific bundles that must exist on the system (array of dictionaries)
all-bundles
Are all of the bundles specified required? (Boolean)
gl-renderer
Required OpenGL capabilities (string)
cl-device
Required OpenCL capabilities (string)
metal-device
Required Metal capabilities (string)
single-graphics-device
Requires that OpenGL, OpenCL, and Metal requirements be met by a single device. (Boolean)
sysctl-requirements
Additional required hardware properties (string)
home
Should installation be allowed in user home directory? (Boolean)
o
The os key defines one or more minimum system versions.
You might have multiple versions if a certain OS update is required for a given major OS version.
For example, if you specify 10.5.4 and 10.6.2, Leopard would be allowed from 10.5.4 up, and Snow Leopard from 10.6.2 up, but 10.6 and 10.6.1 would be rejected.
There is no upper-bound associated with the highest value given.
NOTE: Some of the other requirements imply their own minimum system versions, which may override the values set here. This is noted below where applicable.
o
The arch key specifies the supported architectures, e.g. i386 and/or x86_64.
Note that i386 allows both 32- and 64-bit systems, but if you specify only x86_64, a 64-bit system is required.
o
The ram key specifies the minimum amount of RAM required, in gigabytes.
o
The gl-renderer key specifies a predicate, against which each of the OpenGL hardware renderers will be checked.
For the product to be installed, at least one of the renderers must match the requirements of the predicate.
The given predicate string must be convertible to an NSPredicate, and can use the following key paths:
Key Path
Description
version
The supported OpenGL version as a double (e.g. major.minor).
extensions
An array of OpenGL extension strings supported.
limits.<gl-parameter>
The integer value of the named GL parameter (see below).
limits.param<value>
The integer value of the GL parameter named by enum <value> (see below).
Note that arbitrary GL parameters can be checked via the limits key, using the same symbolic name #defined by the GL headers.
For example:
( version >= 2.0
OR ( ( 'GL_ARB_texture_float' IN extensions OR 'GL_ATI_texture_float' IN extensions ) AND 'GL_ARB_vertex_blend' IN extensions ) )
AND ( limits.GL_MAX_TEXTURE_SIZE >= 1024 AND limits.GL_MAX_TEXTURE_STACK_DEPTH > 8 )
Note that recently-introduced GL parameters may not be recognized by their symbolic names, in which case you can use the alternate form of param<value>, where <value> is the enum (integer) value of the parameter.
For example:
limits.param0x0D33 >= 1024
NOTE:
The gl-renderer requirement is ignored on versions of Mac OS X before 10.6.8.
For this reason, specifying gl-renderer will cause the minimum system version to be raised to 10.6.8.
This may override the values set via the os key.
o
The cl-device key specifies a predicate, against which each of the OpenCL GPU devices will be checked.
For the product to be installed, at least one of the devices must match the requirements of the predicate.
The given predicate string must be convertible to an NSPredicate, and can use the following key paths:
Key Path
Description
version
The supported OpenCL version as a double (e.g. major.minor).
extensions
An array of OpenCL extension strings supported.
limits.<cl-parameter>
The integer value of the named CL deviceInfo parameter.
limits.param<value>
The integer value of the CL parameter named by enum <value>.
NOTE:
The cl-device requirement is ignored on versions of Mac OS X before 10.7.
For this reason, specifying cl-device will cause the minimum system version to be raised to 10.7.
This may override the values set via the os key.
o
The metal-device key specifies a predicate, against which each of the Metal GPU devices will be checked.
For the product to be installed, at least one of the devices must match the requirements of the predicate.
The given predicate string must be convertible to an NSPredicate, and can use the following key paths:
KeyPath
Description
deviceName
The name of the Metal Device that the hardware is using. <string>
supportedFeatureSets
An array of Metal (MTLFeatureSet) feature sets that the device supports. <array<string>>
isRemovable
The device is considered to be removable. This is useful for requiring an eGPU. <bool>
isHeadless
The device can not and does not have any displays attached. <bool>
isLowPowerDevice
Returns if the device is the low power device for automatic gfx switching. <bool>
rasterOrderGroupsSupported
The device supports raster order groups. <bool>
argumentBuffersTier
The graphics buffer tier that the device supports. <integer>
NOTE:
The metal-device requirement is ignored on versions of macOS before 10.14.4.
For this reason, specifying metal-device will cause the minimum system version to be raised to 10.14.4.
This may override the value set via the os key.
NOTE:
An example of an MTLFeatureSet that would go into the supportedFeatureSets array would be MTLFeatureSet_macOS_GPUFamily1_v1 , a list of the current feature sets can be found in MTLDevice.h inside of Metal.framework.
If the gl-device, cl-renderer, and metal-device are specified, all of the requirements must be satisfied.
By default, the requirements are considered met even if one graphics device satisfies the OpenGL requirement and a different one satisfies the OpenCL one (Same with Metal).
If you want to require that a single device satisfies all of the graphics requirements, add the single-graphics-device key with a value of true.
NOTE:
Setting the single-graphics-device to true will only be honored if all three of the graphics types are specified ( gl-device, cl-device, metal-device ).
However, since legacy packages before 10.14.4 are supported, it can also be used if only gl-device and cl-device are specified.
o
The sysctl-requirements key specifies a predicate, against which additional hardware requirements will be checked.
The predicate uses the sysctl(2) facility to obtain hardware properties for the system in use.
Note that only a subset of sysctl(2) variables are available, including most of the hw.* tree and kern.ostype, kern.osrelease, kern.osrevision, and kern.version from the kern.* tree.
For example:
hw.physicalcpu > 1
Or:
( hw.optional.aes == 1 AND hw.memsize >= 4294967296 )
NOTE:
The sysctl-requirements predicate is ignored on versions of OS X before 10.10.
For this reason, specifying sysctl-requirements will cause the minimum system version to be raised to 10.10.
This may override the values set via the os key.
o
The bundle key specifies one or more bundles that must already exist on the system (possibly at some minimum version) for the product to be installed.
For example, this might be appropriate if the product installs a plugin, and you need to ensure that a compatible version of the host application is available.
Each object in this array is a dictionary with the following keys:
Key
Description
id
The CFBundleIdentifier of the bundle (required)
path
The default path of the bundle (required)
CFBundleShortVersionString
The minimum short version string of the bundle (optional)
search
Search for bundle if not found at default path? (Boolean, optional)
The given default path will be checked first.
Only if the bundle does not exist at that path, and search is given as true, the bundle identifier (id) will be used to find the bundle (this is appropriate for applications which the user might move).
If the bundle is found through either method, and its version is greater than or equal to the given CFBundleShortVersionString, the requirement is met.
(If CFBundleShortVersionString is omitted, the bundle need only exist.)
If you specify multiple bundles, all must exist, unless you specify the all-bundles key with a value of false, in which case only one of the bundles must exist.
If the bundle requirement is not met, the Installer must have a localized explanation to display to the user.
This should be provided in the InfoPlist.strings resource of your top-level bundle (as specified with --component), under the RequiredBundlesDescription key.
o
The home key, if set to true, designates that the product can be installed under the user's home directory, as an alternative to installing on the system for all users.
This should be enabled only if the entire product can be installed in the home directory and be functional.
(Home directory installation is disabled by default.)
Note that home directory installation is not supported for the Mac App Store.
SIGNED PRODUCT ARCHIVES
When creating a product archive, you can optionally add a digital signature to the archive.
You will need to have a certificate and corresponding private key -- together called an ``identity'' -- in one of your accessible keychains.
To add a signature, specify the name of the identity using the --sign option.
The identity's name is the same as the ``Common Name'' of the certificate.
If you want to search for the identity in a specific keychain, specify the path to the keychain file using the --keychain option.
Otherwise, the default keychain search path is used.
productbuild will embed the signing certificate in the product archive, as well as any intermediate certificates that are found in the keychain.
If you need to embed additional certificates to form a chain of trust between the signing certificate and a trusted root certificate on the system, use the --cert option to give the Common Name of the intermediate certificate.
Multiple --cert options may be used to embed multiple intermediate certificates.
The signature can optionally include a trusted timestamp.
This is enabled by default when signing with a Developer ID identity, but it can be enabled explicitly using the --timestamp option.
A timestamp server must be contacted to embed a trusted timestamp.
If you aren't connected to the Internet, you can use --timestamp=none to disable timestamps, even for a Developer ID identity.
Note that component packages do not need to be signed (e.g. with pkgbuild(1)) before adding them to a signed product archive.
The signature on the product archive protects the entire product, including the added packages.
If you want to postpone signing the product archive until it has been tested and is ready to deploy, you can use productsign(1) when you are ready to add the signature.
EXAMPLES
productbuild --component build/Release/Sample.app /Applications Product.pkg
Build the archive Product.pkg to install Sample.app under /Applications, synthesizing a distribution.
This is typical for building a Mac App Store archive.
productbuild --product def.plist --component build/Release/Sample.app /Applications Product.pkg
Build the archive Product.pkg to install Sample.app under /Applications, synthesizing a distribution with the requirements from def.plist.
This is typical for building a Mac App Store archive with pre-install requirements.
productbuild --distribution Product.dist --package-path /tmp/Packages Product.pkg
Build the archive Product.pkg using Product.dist, searching for packages referenced by that distribution in /tmp/Packages (as well as in CWD).
productbuild --distribution Product.dist --resources Resources Product.pkg
Build the archive Product.pkg using Product.dist, incorporating the resources found under the Resources directory.
productbuild --distribution Product.dist --sign sample-identity Product.pkg
Build the archive Product.pkg using Product.dist, and sign the resulting archive using the identity sample-identity.
You will be prompted to allow productbuild to access the keychain item, unless Always Allow was chosen previously.
productbuild --package /tmp/a.pkg --package /tmp/b.pkg Product.pkg
Build the archive Product.pkg with the component packages /tmp/a.pkg and /tmp/b.pkg, synthesizing a distribution.
SEE ALSO
pkgbuild(1)
productsign(1)
xcodebuild(1)
Mac OS September 15, 2010 Mac OS
man pkgbuild(これいる？)
pkgbuild(1) BSD General Commands Manual pkgbuild(1)
NAME
pkgbuild -- Build an OS X Installer component package from on-disk files
SYNOPSIS
pkgbuild [options] --root root-path [--component-plist plist-path] package-output-path
pkgbuild --analyze --root root-path plist-output-path
pkgbuild [options] {--component component-path} package-output-path
DESCRIPTION
A ``component package'' contains payload to be installed by the OS X Installer.
Although a component package can be installed on its own, it is typically incorporated into a product archive, along with a ``distribution'' and localized resources, using productbuild(1).
To create a product archive for submission to the Mac App Store, do not use pkgbuild.
Instead, use productbuild(1) directly.
pkgbuild has three different modes, as shown in the SYNOPSIS above:
1.
Package a complete destination root.
When you use xcodebuild(1) with the install action, the result is a destination root, either under /tmp, or in whatever location you specify with the Xcode DSTROOT setting.
Use the --root option to specify that destination root directory to pkgbuild, and the entire contents of the directory tree will be included in the output package.
2.
Create a template component property list (analyze mode).
You point pkgbuild to a destination root as above, but instead of outputting a package, pkgbuild outputs a component property list (see COMPONENT PROPERTY LIST).
By editing this property list and specifying it with --component-plist when you subsequently build the package, you can control bundle-specific Installer behavior.
3.
Package one or more individual bundles.
If you don't have a destination root, you can use the --component option to specify one or more bundles that should be incorporated into the package.
Note that only bundles can be specified with --component.
ARGUMENTS AND OPTIONS
--root root-path
Package the entire contents of the directory tree at root-path, typically a destination root created by xcodebuild(1).
--component component-path
The bundle at component-path is added to the package.
Valid only if you don't use --root.
--component-plist plist-path
If you specify --root, you can use --component-plist to identity the bundles within that destination root, and control how the OS X Installer handles those bundles.
See more at COMPONENT PROPERTY LIST.
If you add bundles and need to update your component property list, you can specify the old version with --component-plist when running pkgbuild with --analyze, and the old settings will be propagated to the output for still-extant bundles.
--scripts scripts-path
Archive the entire contents of scripts-path as the package scripts.
If this directory contains scripts named preinstall and/or postinstall, these will be run as the top-level scripts of the package.
If you want to run scripts for specific bundles, you must specify those in a component property list; see more at COMPONENT PROPERTY LIST.
Any other files under scripts-path will be used only if the top-level or component-specific scripts invoke them.
--nopayload
Indicates that the package will contain only scripts, with no payload.
--identifier pkg-identifier
Specify a unique identifier for this package.
The OS X Installer recognizes a package as being an upgrade to an already-installed package only if the package identifiers match, so it is advisable to set a meaningful, consistent identifier when you build the package.
pkgbuild will infer an identifier when building a package from a single component, but will fail otherwise if the identifier has not been set.
--version pkg-version
Specify a version for the package.
Packages with the same identifier are compared using this version, to determine if the package is an upgrade or downgrade.
If you don't specify a version, a default of zero is assumed, but this may prevent proper upgrade/downgrade checking.
--install-location install-path
Specify the default install location for the contents of the package.
For example, if you specify a single application component, you might specify an install-path of /Applications.
pkgbuild attempts to infer a sensible install path if this option is not used, but it may not choose correctly.
Note that whether or not the default install location is actually used by the OS X Installer depends on the distribution file you deploy with the package.
--analyze
Instead of creating a package, create a template component property list from the destination root given with --root.
See COMPONENT PROPERTY LIST.
--prior pkg-path
In addition to the options above, you can also set the package identifier, version and install location by pointing to a prior version of the same package.
pkgbuild will read the package at pkg-path and use the same package identifier and install location contained therein.
The version number in the prior package will be converted to an integer and incremented, and the result used for the new package.
Note that pkgbuild makes no attempt to verify that the prior package is in any way equivalent to the one being built, so you must make sure you point it to a logically equivalent package.
--filter filter-expression
By default, --root will include the entire contents of the given root-path in the package payload, except for any .svn or CVS directories, and any .DS_Store files.
You can override these default filters by specifying one or more --filter options.
Each filter-expression is an re_format(7) ``extended'' expression: any path in the root which matches any of the given expressions will be excluded from the package payload.
(Note that specifying even one --filter inhibits the default filters, so you must respecify the default filters if you still want them to be used.)
--ownership (recommended | preserve | preserve-other)
By default, when the payload is archived into the package, the recommended UID and GID will be applied to all files.
(Generally, this will be root:wheel, which ensures that files installed in the system domain are root-owned, while files installed in the user home directory will be owned by that user.)
If you have special ownership requirements, you should use chmod(1) to adjust the ownership of the source files, and use --ownership preserve so that pkgbuild archives the exact ownership of the on-disk files.
Alternatively, if you have just a few files to adjust, --ownership preserve-other will apply the recommended UID and GID to those files that are owned by the user running pkgbuild, but leave other files unchanged.
Note that pkgbuild never changes the ownership of the actual on-disk files, only the ownership that is archived into the package.
--sign identity-name
Adds a digital signature to the resulting package.
See SIGNED PACKAGES
--keychain keychain-path
Specify a specific keychain to search for the signing identity.
See SIGNED PACKAGES
--cert certificate-name
Specify an intermediate certificate to be embedded in the package.
See SIGNED_PACKAGES
--timestamp=none
Disable trusted timestamp, regardless of identity.
See SIGNED_PACKAGES
--quiet Inhibits status messages on stdout.
Any error messages are still sent to stderr.
package-output-path
The path to which the package will be written.
plist-output-path
When --analyze is used, the path to which the template component property list will be written.
COMPONENT PROPERTY LIST
When you package a destination root, you can use a component property list to specify how bundles in that root should be handled by the OS X Installer.
This property list should be an array of dictionaries, where each dictionary specifies a single bundle.
The dictionary keys are as follows:
Key
Description
RootRelativeBundlePath
Path to bundle relative to the destination root (string)
BundleIsRelocatable
Install bundle over previous version if moved by user? (bool)
BundleIsVersionChecked
Don't install bundle if newer version on disk? (bool)
BundleHasStrictIdentifier
Require identical bundle identifiers at install path? (bool)
BundleOverwriteAction
How to treat existing on-disk version of bundle (string)
BundlePreInstallScriptPath
Relative path to bundle-specific preinstall script
BundlePostInstallScriptPath
Relative path to bundle-specific postinstall script
ChildBundles
Bundles under this bundle (array of dictionaries)
The easiest way to create a component property list is to use the --analyze option and point pkgbuild at your current destination root.
The output will be a component property list with default attributes, which you can then edit as needed.
You can also specify a previous version of your component property list when using --analyze, which will cause the attributes of previously existing bundles to be propagated forward.
BundleOverwriteAction specifies how an existing version of the bundle on disk should be handled when the version in the package is installed.
If you specify upgrade, the bundle in the package atomically replaces any version on disk; this has the effect of deleting old paths that no longer exist in the new version of the bundle.
If you specify update, the bundle in the package overwrites the version on disk, and any files not contained in the package will be left intact; this is appropriate when you are delivering an update-only package.
Another effect of update is that the package bundle will not be installed at all if there is not already a version on disk; this allows a package to deliver an update for an app that the user might have deleted.
BundlePreInstallScriptPath and BundlePostInstallScriptPath are meaningful only if --scripts was used to specify a scripts directory.
The paths given by these keys must be relative to the scripts directory.
ChildBundles can be used to represent nesting of bundles, but it does not change the meaning of RootRelativeBundlePath within lower-level dictionaries (i.e. it is always relative to the destination root).
If you write a component property list manually, you do not need to use ChildBundles at all; you can simply put all bundle dictionaries in the top-level array.
SIGNED PACKAGES
When creating a package, you can optionally add a digital signature to the package.
You will need to have a certificate and corresponding private key -- together called an ``identity'' -- in one of your accessible keychains.
To add a signature, specify the name of the identity using the --sign option.
The identity's name is the same as the ``Common Name'' of the certificate.
If you want to search for the identity in a specific keychain, specify the path to the keychain file using the --keychain option.
Otherwise, the default keychain search path is used.
pkgbuild will embed the signing certificate in the product archive, as well as any intermediate certificates that are found in the keychain.
If you need to embed additional certificates to form a chain of trust between the signing certificate and a trusted root certificate on the system, use the --cert option to give the Common
Name of the intermediate certificate.
Multiple --cert options may be used to embed multiple intermediate certificates.
The signature can optionally include a trusted timestamp.
This is enabled by default when signing with a Developer ID identity, but it can be enabled explicitly using the --timestamp option.
A timestamp server must be contacted to embed a trusted timestamp.
If you aren't connected to the Internet, you can use --timestamp=none to disable timestamps, even for a Developer ID identity.
Note that if you are going to create a signed product with the resulting package, using productbuild(1), there is no reason to sign the individual package.
EXAMPLES
pkgbuild --identifier com.sample.pkg.app --root /tmp/Sample.dst Sample.pkg
Build the package Sample.pkg using the entire contents of the destination root /tmp/Sample.dst.
pkgbuild --analyze --root /tmp/Sample.dst components.plist
Analyze the destination root /tmp/Sample.dst, and write a template component property list to components.plist.
pkgbuild --identifier com.sample.pkg.app --root /tmp/Sample.dst --component-plist components-edited.plist Sample.pkg
Build the package Sample.pkg using the destination root /tmp/Sample.dst, using the bundle-specific behaviors indicated in components-edited.plist.
pkgbuild --identifier com.sample.pkg.app --root /tmp/Sample.dst --sign sample-identity Sample.pkg
Build the package Sample.pkg using the destination root /tmp/Sample.dst, and sign the resulting package using the identity sample-identity.
You will be prompted to allow pkgbuild to access the keychain item, unless Always Allow was chosen previously.
SEE ALSO
productbuild(1), xcodebuild(1)
Mac OS September 15, 2010 Mac OS
man xcodebuild(これいる？)
(Xcodeを入れないとツールが出現しない)
(パンピーなのでXcodeを入れてない)
暇になったら頑張って見てみます
感想
はえ〜知らない世界がいっぱいって感じだぁ・・・
こっから先はもう全てが開発者の領域なのか・・・
わかったこと
何か気づいたらまた追記しようかな・・・
.pkgについて
.pkgはインストーラ.appが展開して中身をMacにインストールされるものだが，一般的にディストリビューションとして配布されているものはFinderからでは中身が見えない("パッケージの内容を表示"が使えない)，そして一般的な解凍ツールも使えない(unrarやらunzipやらuntarやらのツールが効かないんだがみたいな質問をSOFで見つけた)ため，.pkgによってどんなものがインストールされるのかを事前に知る手段としてpkgutilコマンドが使える．
macOSにおけるディストリビューションな.pkgについてはLeopard(10.5)以降に仕様変更がなされており，統一化された構造を持つBOM(Bill of Materials)ファイルの1種(一般的な意味でのBOM(byte order mark)ファイルとは意味合いが異なる)でありMac OS X固有の形式である．
どうもそのLeopard時の仕様変更でインストーラ.appや他のmacOS純正のツールでしか中身を利用することができなくなり，逆にLeopard以前はバンドルとして中身が見れたらしい，そしてその過渡期がどのような感じだったのかは知らない．
pkgutil以外にもBOMファイルを解体する方法としてlsbomがあったりするが，.pkgに関して言えばpkgutilが推奨されているような雰囲気を感じる．
しかしそうやって配布されるディストリビューションな.pkgの中にも.pkgが入っており，つまり1つ以上の.pkgを用いて最後にディストリビューションな.pkgファイルに整形するようだ超絶ややこしいなオイ．
1つの.pkgファイルに整形することをflatten・その逆に分解することをexpandと呼ぶ．
そしてそんなpkgutilが出る前に開発されたunpkgは既に.pkgの分解ができていたらしい，開発者(第三者)の執念を感じる・・・
.pkgの構成
FreeBSDだとかUnixだとか色々調べても理解できなかったぜ．
インストーラーの役目を果たす.pkgとそこに内包される.pkgがあるのはわかったが，それに関連するファイルがどこにどうやって存在しているのかがわからないし，そしてどのツールでどこまで覗けるのか全くわからない分解して良さそうな某pkgでちょっとやってみた．
mpkg？知りませんね・・・
つまるところユーザーに手動でコピペしてもらうのが面倒なセッティングを開発者がやって欲しい時にそれを代替してくれる方法が.pkgのインストールで，installer.appの仕様の通りに，つまりpkgbuildとproductbuildの要求の通りにファイルを配置すればインストーラが完成する・・・？その仕様が一朝一夕じゃわからねぇって話よ
(例)
XXX
┣━content.pkg
┃ ┣━Payload
┃ ┃ ┣━Library
┃ ┃ ┃ ┣━Application Support
┃ ┃ ┃ ┃ ┗━documents...
┃ ┃ ┃ ┣━Extensions
┃ ┃ ┃ ┃ ┗━kexts...
┃ ┃ ┃ ┣━Frameworks
┃ ┃ ┃ ┃ ┗━frameworks...
┃ ┃ ┃ ┣━LaunchAgents
┃ ┃ ┃ ┃ ┗━???(invisible)
┃ ┃ ┃ ┣━LaunchDaemons
┃ ┃ ┃ ┃ ┗━???(invisible)
┃ ┃ ┃ ┗━Preferences
┃ ┃ ┃ ┗━preferences file...
┃ ┃ ┗Applications
┃ ┃ ┗apps...
┃ ┣━Scripts
┃ ┃ ┣━Support
┃ ┃ ┃ ┗datas...
┃ ┃ ┣━preinstall
┃ ┃ ┗━postinstall
┃ ┣━Bom
┃ ┗━PackageInfo
┣━Distribution
┗━Resources
┗datas...
pkgbuildとproductbuildのおかげで構造は大体同じになるのかぁ・・・
PackageInfoとDistributionはxml形式のファイルで，前者にはcontent.pkgに関する情報が，後者にはインストール時の挙動制御に関する情報が書かれている(バイナリ読んだ，サンキューiHexくん)．
BOMはBOMStoreなる形式で一体化されたPayloadを分解するための辞書の役割をしている，.appをバンドルとみなした時の配下の素材ファイルまで網羅しているくらいには微細に記述されている・・・
LaunchDaemonsとLaunchAgentsのフォルダはなんか見る権限すらないと言われてしまった，ソフトをインストールさせた後で任意タイミングで実行させたい(起動後にオートで起動etc)時にpostinstallとpreinstallを用意し，それに関する情報を.plistとしてLaunchAgentsに置いておく，弄らない方が吉ってことか(すっとぼけ)
pkgutil
Snow Leopard(10.6)で追加されたらしいコマンド．なぜLeopardで実装しなかったのか
導入済みの.pkgをリストアップしたり検索したりもできるが，アンインストールを行う場合は手動でのrmが必要．
pkgutilが保持する記録を削除することができても実体を削除できるわけではない，そして関連のファイルも当然だけど残ったままなので丁寧な手動の削除が必要．
つまるところ開発者がちゃんとアンインストーラを用意しているならそっちを使ったほうがおそらく確実・・・？アンインストーラの作り方みたいな記事が見当たらないのでそこら辺はどうなってるんだろうなぁと気になってはいる，どうやってpkg周りの履歴まで後を濁さずキレイに消してもらえるのか・・・
あとmanページにSEE ALSOって言われたから他のツールの解説も見たけど，installerはまだしも残りの3つは何が何だかさっぱりやわ．そういう立場の人間になったら読むかもしれへんけど今は遠慮させてもらいますわ．
レシート系とファイル系
LinuxとかUnixの話も絡むが，10.16.6において.pkgをインストールすると必ず/Library/Receipts/InstallHistory.plistに履歴が残っている．
他にも**.pkgそのものだったりBOMファイル**だったりが残っているらしいけど，OSのバージョンによって収納先が微妙に違うらしい．
レシート系の操作は先のInstallHistory.plistを用い，ファイル系の操作は.pkgを用いる．
/Library/Receipts
10.7まではサードパーティー系は全てここだった(というかここにあるから削除してねという写真付きの古い記事を見かけた)．
残っている痕跡も最終更新が2017年初頭のApple純正アプリについてだけなので，現時点では先のInstallHistory.plist以外はマジで機能していなさそう．
/Library/Apple/System/Library/Receipts
Apple純正アプリの追加リソースみたいなものは全てここにあるっぽい．
LogicProXの追加音源とかFCPXのプラグインとか・・・
/private/var/db/receipts
サードパーティー系は現在全てここに収納されている．
たぶんギリSIPには入っていないはず(SIPの話はkextの昔話をしたい時にでもまた・・・)
dmgとVolume
dmgをダウンロードしてDiskImageMounter.appで展開してVolumeとしてmacOSに接続した後でVolumeの中の.pkgをInstaller.appでインストールするのが現在のmacOSの作法らしい．
フルパス記法
Volume接続なのでこうなる(例)
/Volumes/WacomTablet/Install\ Wacom\ Tablet.pkg
これはたぶんこういうことだと思う
/Volumes/(Volumeの名前)/Install\␣(開発元名)\␣(インストーラ名).pkg
今後もしかしたら使うかもしれないので覚えておく．
\ <=しかしコレの付け方の規則がわからん，なんで2つも必要なんだ・・・
(わからなければtab連打で候補が出てくるから気にすんな，それはそう)
導入済み.pkgを確認
レシート系呪文，インストールしたディストリビューションな.pkgの一覧を取得できる．
$ pkgutil --pkgs
これで一覧が出力される
.pkgでインストールされるであろうファイルの名前を確認
ファイル系呪文，ディストリビューションな.pkgをインストールした際にどんなファイルが導入されるかを確認できる．
(例)
$ pkgutil --payload-files /Volumes/WacomTablet/Install\ Wacom\ Tablet.pkg
たぶんこういうことだと思う
$ pkgutil --payload-files (調査したい.pkgファイルのフルパス)
もしかして非ディストリビューションな.pkgはインストールされるものという扱いがされないからエラー吐かれるんじゃ・・・
Payloadってなんだ
"Payload"という名前のファイルがディストリビューションな.pkgの中にあるが，実態はインストールさせたい中身そのものを1つのファイルにまとめたもので，productbuildされる前はただのフォルダだったらしい．
それがどんな名前のファイルの集合体かをBOMファイルを読んでユーザーに教えてくれるのがこのコマンドなのかなぁ・・・kextバンドルの中身の構成まで教えてくれてるし・・・
.pkgの中身を入手する
.pkgの中身を1つのディレクトリに変換する，要するにexpandする．
注意
自分で勝手に作ったものならまだしも，その他の場合だと規約違反になる気がする
悪用，ダメ，絶対
(例)W●c○m「そんなことやめろよな？」
2.2 【制限】ユーザーは、本契約によって明示的に許可される場合や、ディザスタ・リカバリ、プログラムのエラーの確認、バックアップを目的とする場合を除いて、本ソフトウェア（文書を含む）の複製または使用を行いません。ユーザーは、本ソフトウェアの修正、翻訳、配布、その派生物の作成、担保入れ、再ライセンス付与、二次ライセンス付与、賃貸、賃借、リース、また、第三者の研修、営利的タイムシェアリング、サービス機関での使用を目的とした本ソフトウェアの使用を行ってはならず、いかなる第三者によるこれらの行為をも許可したり、奨励したりしてはならないものとします。ユーザーは、適用法によって明示的に許可されている場合のこの許可範囲を除き、本ソフトウェアのリバースエンジニアリング、分解、デコンパイル、本ソフトウェアに使用され、組み込まれているソースコード、アルゴリズム、方法、技術の究明を行ってはならず、いかなる第三者によるこれらの行為をも許可したり、奨励したり、可能にしたりしてはならないものとします。ユーザーは、本ソフトウェアを、本ソフトウェアとの併用のみが可能な第三者の製品と使用せず、いかなる第三者にも、これらの行為を奨励したり、可能にしたりしてはならないものとします。ユーザーは、本ソフトウェア内または本ソフトウェア上にある商標、著作権、その他の所有権および制限付き権利の情報、説明文、記号を、除去または改変してはならないものとします。
コレを実行すると「複製」に該当する可能性があるので私はやめておきます，皆さんもしないでください
それに先の記事の時点で目的のエラー(?)も解決してしまったので，今からコレをやっても「プログラムのエラーの確認」に該当しない・・・一足遅かったか・・・
以上を踏まえた上で
本来は自作の.pkgを再編集したい時にコレを使うらしい・・・それを踏まえた上で構文だけ・・・
$ pkgutil --expand (解体したい.pkgファイルのフルパス) (中身を置いときたいディレクトリのパス)
パスは新しく作る必要があるためかぶらないパス名を与えなければダメ(自己指定もNG)らしい．
しかしそもそもこれってディストリビューションな.pkgにもそうでない.pkgにも使えるの？
payloadの中身すら展開する
$ pkgutil --expand-full (解体したい.pkgファイルのフルパス) (中身を置いときたいディレクトリのパス)
本来は開発段階ではpayload化されない(BOM生成しない)ので使わないものと思われるが，productbuildでpayload化されたものを解体するのはfullをつけて実行すると可能．
ただしmanに載っていないネットの海で拾ったコマンドなので何とも言えない，Appleが想定したものかどうかは置いといてgithubでコレ使えばええやんみたいな会話を見たんだけど・・・
.pkgの中身を元に戻す
私は開発者ではないのでよくわからないが，一度-expandした.pkgを元に戻せるらしい，
$ pkgutil --flatten (中身が置かれているディレクトリのパス) (復元したい.pkgファイルのフルパス)
pkgbuild・productbuildとは訳が違い，--expandと対応して元に戻すことのみできる・・・？
installer
.pkgをインストールできるpkgutilのような詳しい操作は行えないインストール専用ツール・・・？
productbuild
.pkgをアーカイブ化？ディストリビューション化？できるらしい
ディストリビューションな.pkgとして配布する際には最後に必ずこれを実行せねばならない，色々な情報を付加してようやくインストーラ(集大成の.pkg)になる．
pkgbuild
.pkgを生成できるらしい，コレで生成されるのは本来は展開不可能な.pkgであり，ディストリビューションな.pkgをexpandして得られる展開可能な.pkgの方がむしろ変な存在だった．
この状態からであればexpandとflattenの行き来ができる，Payload化はされていないもよう
xcodebuild
xcodeで作ったプロジェクトをビルドできるらしい
unpkgについて
概要
npmとかで聞かれるCDNサービスのunpkgじゃなくて，.pkgファイルをガチで解体するツールの方のunpkg．
timdougさんが作っている.app形式のGUIツール．
歴史
初登場はPowerPC時代の2005年でv1.61，ユニバーサルバイナリになったv2.0が2006年に登場して以降，日本語の記事でunpkgを扱うものがちょくちょく検索でひっかかる．
2019年10月22日にCatalina向け64bitバイナリのv4.6が出ているので，なんとバリバリ開発継続中の老舗ソフト．
使い方
https://www.timdoug.com/unpkg/ からzipを落として回答するかbrew cask install unpkgするかでunpkg.appを召喚して，セキュリティとプライバシーから未確認アプリとしての実行を許可すれば起動できる．
あとは好きな.pkgを選んで解体を実行すればオーケー・・・？
(前述お理由で私はまだ試していないのでなんとも言えない)
感想
GUIでやれるのはきっと便利なんだと思う，terminalからややこしいpkgutilを使わなくてもいいし・・・
そして確かに昔は妙な.pkgをインストールして痛い目にあったみたいな事例があったかもしれないし，製作者さんだってI dislike .pkg files on Mac OS X.って言ってるあたり，昔はそれなりに酷かったんだろうなぁって
でも最近のAppleがゴリゴリに規制をかけてくれたおかげでユーザーがインストールできる.pkgは総じて安全安心なものになったと言えるのでは・・・？もう普通にMacを使うだけならunpkgしなくてもいいんじゃないかな・・・
結論
無闇な解析はやめよう！
ルールは守ろう
わからんなら自分で作ってみよう！
rmってunlinkって別名があるのか
知らんかった