No Packages Eligible For Install Mac

To import a Symantec Endpoint Protection (SEP) client package into the manager:

How to fix OS X Installer Failure 'No packages were eligible for install. Contact the software manufacturer for assistance'. Posted by Scott on Friday, November 2. If you ever get this error while attempting to install OS X, you will likely need to set the date using terminal. “No packages were eligible for install” is a message that appears when attempting to install OS X El Capitan on older macs. MacBooks are a very popular purchase in Melbourne and around Australia so it is important to understand the reasoning behind why this message appears. Simply put, if your Mac isn’t old enough to run the latest El Capitan operating system then it won’t install.

Log into the SEPM Console
Select the Admin tab.
Select Install Packages.
Click Add Client Install Package from the Tasks menu.
On the Add Client Install Package dialog:
1. Provide a descriptive name for the installation package in the Specify a name for this package text box (i.e. Symantec Endpoint Protection 12.1 RU5 Mac Client)
2. Click Browse.
3. Navigate to the installation package folder (i.e. SEPMPackages from the Part 1 installation media)
4. Select the .info file associated with the installation package (i.e. SAV32.info, SAV64.info, SEP_MAC.info)
5. Click Select.
6. Optionally, provide a description of the package in the Description field.
7. Click OK to start the import process.
After a successful import, a status window will be displayed.
Click Close to exit the Creating Package dialog.

After a successful import, a 'Package is created' event will be logged into the System/Administrative logs. Details will describe this new package with text similar to 'Successfully imported the SEP 12.1 RU5 32-bit package via Symantec Endpoint Protection Manager. This package is now available for deployment.'

Notes:

This process will not work with the SEPM web console. It can only import packages that were exported in the .ZIP file format. It will not import a .INFO file format package, it's not supported for web console. The web console can only import or export a single file.
It is possible to import an executable package (i.e. .EXE or .ZIP file packages) directly, but this is not recommended. The .INFO file contains extra information that describes the package and ensures proper migration to future builds of the SEP client via delta updates.

OSX flat packages are single installer files with .pkg file extensions.

They appear to have originated with OSX 10.5. You can’t install these fileson OSX < 10.5.

The previous packaging formats were bundles rather than single files:

bundle: A structured directory hierarchy that stores files in a way thatfacilitates their retrieval (see glossary in the software delivery legacyguide)

See OSX legacy packaging redux for details.

As far as I know there is no Apple document describing the flat packageformat.

You may find these other pages useful as background:

A MacTech flat package article;
An introduction to the flat package format;
A guide on unpacking flat packages manually;
A comprehensive stackoverflow package building answer.

About the examples on this page¶

I wrote this page in reStructuredText (reST) for Sphinx, with some customSphinx extensions. The extensions pick up the code fragments in this page andrun them on my laptop as part of the build process for the web pages. Theyalso write out the example files listed on this page. The combination meansthat, at the time I last built the website, I confirmed that the code ran onmy laptop, and gave the output you see here.

Flat packages in general¶

Flat packages are xar archives (see the xar man page).

To see the contents of a flat package, the most convenient command ispkgutil--expand, as in:

This will unpack product archive (meta-packages) and their component packages,and allows you to futz with the directory contents in an_output_dir beforereconstituting the package with:

On OSX, tar will unpack xar archives, and will automatically detect thatthe archive is in xar format with tarxfmy.pkg, if you really want to dothe unpacking without pkgutil.

Different package types¶

Flat packages can be of type:

product archive – a meta-package format containing one or morecomponent packages with an XML file specifying the behavior of theinstaller, including system and volume requirement checks giving informativeerror messages. See the productbuild man page for more detail.
component package – an installer to install one component. Generallyincluded as part of a product archive but can be used as an installer inits own right. A component package installer cannot control the behavior ofthe installer, but can abort the install or raise a post-install errorvia preinstall and postinstall scripts.

Component installer¶

A component installer goes through these stages:

Runs preinstall script if present. An exit code other than zero abortsthe installation.
Writes payload to one or more locations on the target volume
Runs postinstall script if present. An exit code other then zero givesan error message.

We start with some component packages that only have scripts and no payload,to show how they work.

Component installer scripts¶

Contents of scripts/preinstall

Contents of scripts/postinstall

The scripts need to be executable:

Each package needs a package identifier to identify it to the database ofinstalled packages on the target system.

You can list the recorded installed packages on target / with:

Build the package with a fake identifier:

Install the package:

Check the scripts ran by looking for output:

Exit code other than zero causes the installer to give an error message:

Contents of scripts/postinstall

Fixed if the script is not run:

There are some useful environment variables available to thepreinstall, postinstall scripts:

Contents of scripts/preinstall

Here are the new environment variables inserted by the installer:

These appear to be a superset of the environment variables listed for the oldbundle installers at install operations.

No payload, no receipt¶

These “scripts only” installers have no payload, and write no package receiptto the package database:

Payload¶

A flat-package component installer can install one or more bundles to givenoutput locations on the target filesystem.

There are two ways of specifying payload with target location:

Using a destination root, using --root flag to pkgbuild. Thisanalyzes a given directory root-path taking this directory to representthe root / directory of the target system. The installer will copy eachdirectory at root-path to the target system at the same relativefilesystem location.
By individual bundle component, using --component flag topkgbuild. Specify directories to copy, and give their output locationsseparately using the --install-location flag.

Destination root¶

Do the install:

This install did write a package receipt:

Explicit component(s)¶

We point to a bundle to install and (usually) specify the install location.

In this case the bundle must be a properly formed bundle of some sort.

I’ll make a debug symbols bundle by doing a tiny compilation with clang:

Build, install the package:

The installer has written the expected output files:

You can add more than one bundle to a single component installer.

Here I make another bundle with a different name:

When you add more than one component, you need to give a package identifier,because pkgbuild will not know which component to get an identifier from.

Product archive¶

Component packages give a very basic default install.

Product archives allow you to wrap one or more component installs with aninstall configuration that includes:

custom welcome, readme, license and conclusion screens;
custom system requirement and volume requirement checks with informativeerror messages using Javascript code;
ability to customize choices of component packages to install usingJavascript code.

An XML file named Distribution specifies these options (see distributiondefinition file).

Building product archives with `productarchive`¶

productarchive has five modes of action:

Archive for “in-app” content¶

This appears to be something to do with the App Store. Use the --contentflag for this one.

Archive from destination root¶

Build an archive from a directory where the paths of the files relative to the--root directory give the output install location on the target volume(see Destination root).

Archive from component bundle(s) or package(s)¶

Build a product archive from one or more components by passing:

bundle path(s) with one or more uses of the --component flag (seeExplicit component(s)) and / or;
package paths(s) with one or more uses of the --package flag.

Build product archive with two component bundles:

Make bundles into component packages:

Build product archives from the component packages:

Build a `Distribution` file from component bundle(s) / packages(s)¶

This builds a template Distribution XML file by analyzing one or morecomponents in the form of bundles or .pkg files. Use the --synthesizeflag.

Analyze two component bundles to give a Distribution file:

Analyze two component packages to give a Distribution file:

Archive from `Distribution` file¶

Build a product archive from a pre-existing Distribution file, using the--distribution flag. The Distribution file refers to pre-existingcomponent .pkg files. If these are not in the current directory, you cangive paths to find .pkg files with the --package-path flag.

Customizing the `Distribution` file¶

See: distribution definition file and installer Javascript reference.

Adding system and volume checks¶

Contents of distro_check.xml

Now make the volume check fail:

The volume check gets run on every candidate volume; each volume that passesthe check is eligible for the install.

Debugging `Distribution` Javascript with `system.log`¶

Getting the Javascript right can be tricky because it is running in a highlyspecific environment. system.log() can help.

Contents of distro_debug.xml

Use the -dumplog flag to the installer to see the log.

Adding custom script checks¶

You can add custom executable scripts or binaries to run via the Javascriptfunctions such as the volume check and the system check.

You first have to enable the allow-external-scripts option in theDistribution file XML:

This will cause the installer GUI to ask if you want to allow an externalscript to check if the software can be installed.

You can then call external programs via the Javascript system.run()function. The programs you call with system.run either need to be on thesystem PATH that the installer uses, or provided in the installer, usually viathe --scripts flag to productbuild. Here’s an example of a commandalready on the path:

Contents of distro_system_run.xml

Check the script ran:

Here’s an example of a custom script:

Contents of distro_custom_run.xml

Make a directory to contain the test script:

Use test script to look for any interesting environment variables available tothe custom script:

Contents of archive_scripts/my_test_cmd.sh

The script must be executable:

Build the product archive with --scripts flag:

Check the environment variables available to the custom script. We alreadyhave /tmp/my_sudo_envs.log with the standard environment variablesavailable as root, so look for the difference:

There do not seem to be any environment variables to tell us where theinstaller .pkg file is. Here we can work out which volume the installeris installing to with the SUDO_COMMAND variable, but this will only workfor command line installs - the installer GUI does not set this variable.

Customizing the installer pages¶

See distribution definition file for details.

You can customize these pages:

Welcome (<welcome.../> element)
Readme (<readme.../>)
License (<license.../>)
Conclusion (<conclusion.../>)

To do this, you specify the filename containing the custom text, and theformat of the file. For example:

The file should be in the Resources/<language>.lproj directory of theinstaller .pkg, where <language> is a language like “English”,“French” or “Spanish”, or shorthand for these such as “en”, “fr”, “es”. Youcan provide a Resources directory with the --resources flag toproductbuild.

Contents of my_resources/English.lproj/welcome.html

Contents of distro_welcome.xml

We use the --resources flag to add the resources directory: