ON IPS FAQ

The final days of SVR4 packaging as a delivery mechanism for Solaris are coming quickly.  OpenSolaris has been delivered using IPS since its original release in 2008.05, and the Sun Storage 7000 Series also uses the Nevada codebase but not the ON SVR4 packages.  All consolidations will be moving to delivering IPS repositories to Release Engineering (RE) rather than SVR4 packages before Solaris Next.  This page describes FAQs about ON's transition to delivering an IPS repository to Release Engineering and stopping its SVR4 deliveries.

Topics

• Key links
• What's changing for developers?
• How will I build my bits?
• How will I install and test my bits?
• How do I install additional ON packages?
• How do I make packaging changes?

Key links

Questions about this project are best addressed to on-ips-dev@opensolaris.org, where a number of developers are available to answer queries.  We'll manually approve all non-spam, but if you want to not get caught up in manual moderation of the alias, subscribe to the mailman list by sending a mail to  on-ips-dev-subscribe@opensolaris.org.  You can also view the archives at http://mail.opensolaris.org/pipermail/on-ips-dev/

Many questions are answered by one of these documents.  Please review them carefully.

Flag Day message

usr/src/pkg/README.pkg

ON IPS Technical TOI Slides

General IPS Documentation

What's changing for developers?

Please see the Flag Day message for details.

How will I build my bits?

More details on how to build are available in the project's README.pkg, but a general overview is included below.

nightly

You should continue to use nightly with -t to drive automated builds.  You must use the new nightly, and can build that by
ws $CODEMGR_WS; cd usr/src/tools/scripts; make; ^D
Nightly has been updated to build IPS repositories when the -p option is specified.  The IPS repositories will be placed in $CODEMGR_WS/packages/$MACH/nightly[-nd].

bldenv and make

Once you've got a populated proto area, and your environment is setup correctly with bldenv, you can also
cd $CODEMGR_WS/usr/src/pkg; dmake install; dmake check
which will build an architecture-specific repository and place it in $CODEMGR_WS/packages/$MACH/nightly[-nd].  The make check will do a protocmp-style check against your proto area to ensure that all bits are packaged and all packages describe bits in the proto area.

How will I install and test my bits?

Install

Cap-I Install will continue to work unchanged for developers making kernel-only changes.

pkg image-update

pkg image-update is the tool our customers use to upgrade their systems.  It is also the preferred tool now for updating ON bits to nightly, project, or developer bits.  Today, this requires a server, pkg.depotd, to be started to serve your package repository.  In the future, a server will not be required.  However, starting the server is not a challenging step, and we'll be providing a script called onu to set up your test machine or desktop, start a server, and update to your bits all with one command, but using only supported interfaces under the covers.

After you've built your repository, this is done by starting pkg.depotd on your test machine against an NFS mounted repository from your build machine.  If your test machines and build machines are connected by a slow or bandwidth-limited network, there's benefit in copying the repo close to the test machines, especially if there are multiple to update.  In some cases, running the repo on the build machine is the right choice, but developers will need to manage that shared resource as they do disk space usage.

More details on doing image-update are available in the project's README.pkg.

BFU, but only temporarily

BFU will be removed about 2 builds after initial integration of the IPS bits.  pkg image-update is very similar to what BFU used to do, but in a form that is supportable and used by our customers.  When developers use the same tools as our customers to install and upgrade their bits, the quality of the product increases.  If there are flaws with our supported tools, please help our customers by investing in improving those tools rather than creating developer-specific one-offs.  The IPS team welcomes contributions.

PIT

Both DIY and project PIT will be able to accept IPS repositories for test runs.

Testing Install

Testing install as our customers will see it is a much easier process on OpenSolaris than it was on Nevada.  Developers making changes which may impact the install environment should use the Distribution Constructor to assemble an IPS-based install image to test from.  Minor changes to the process are required, but the basic steps are covered here: http://blogs.sun.com/lianep/entry/testing_on_changes_with_opensolaris

QSun Internal) How do I get OpenSolaris on my OPG lab machines?

A: http://labspace.central.sun.com/wiki/index.php/OpenSolarisInstallDirections

Q:What about using ACR?

A: The SVR4 package postinstall scripts ACR invoked are being removed.  If you're adding a driver, or need a driver added, you'll need to modify your driver files (name_to_major, etc.) by hand.  Doing so is a good sign you should be testing on IPS-installed systems instead.

How do I install additional ON packages?

If you've used onu, or want to install additional ON packages from your workspace, you currently need to learn to start up a depot manually.  These instructions are included in README.pkg, but are fairly straightforward.

On your build machine,
cd $CODEMGR_WS/packages/$MACH/nightly[-nd]
/usr/lib/pkg.depotd -d repo.redist -p <port> &

If you're building without ON_CRYPTO_BINS set, you also need the on-extra repository.
/usr/lib/pkg.depotd -d repo.extra -p <different-port> &

Make SURE you choose an unused port and the depot starts successfully.

Configure your test system.
pkg set-publisher -P -g http://<your server host>:<port> on-nightly
Again, if you're building without ON_CRYPTO_BINS set:
pkg set-publisher -g http://<your server host>:<different-port> on-extra

Then you can install additional packages with pkg install <package>.  If you wish to do this after onu but before reboot, look at where your new BE is mounted with beadm list, and then use the -R option to pkg install to install the package in your new BE.

Alternatively, after installation but before onu, install the package and onu will take care of upgrading it for you.

How do I make packaging changes?

For an overview, read the project's README.pkg and the pkg(5) manpage on your OpenSolaris system.

Q: What about my postinstall, class action, and other packaging scripts?

A: The most common modification to postinstall scripts is to modify driver files.  Driver file updates are now done declaratively in the package manifest in a driver action.

For other postinstall scripts, please read about how to avoid writing packaging scripts which must work in a wide variety of install and upgrade contexts and replace them with self-assembling software.  http://src.opensolaris.org/source/xref/pkg/gate/doc/scripting.txt

Q: Doesn't someone else own the packaging of my software?

A: Sorry, but there are no magic packaging elves introduced with the switch from SVR4 to IPS.  As with SVR4, each technology owner remains responsible for ensuring that their software components install and upgrade properly through the packaging system.  Because we've changed to a new packaging system, this will likely involve more diligence than it has while we were not investing in and thus not changing installation and packaging technologies for our customers.