Wyllys Ingersoll wrote:
Is there a page somewhere that documents the procedure for converting existing SRV4 package
action scripts into something that IPS can use? I'm in the final stages of preparing
a project for putback and someone asked about making the packaging changes
"IPS" ready,
but nobody I've asked seems to have a definitive answer about whether or not
that is
a requirement or how to go about doing it.
- Are all current projects that modify existing class action scripts required
to convert
them to IPS or make them "IPS-friendly" ?
While it's currently not a strict requirement for putback (though it will
be over the coming months, and the ON cteam is already asking about it),
if upgrade fails from one supported OpenSolaris release to another, a bug
is likely to wind its way through the opensolaris team and back onto your
plate.
It's a good thing to make a product that we ship externally regularly
work, and the best time to do that is at putback.
If yes, is there a page documenting the steps and procedures and
requirements that
a developer needs to make the transition?
The instructions are fairly simple. IPS doesn't run any postinstall or
class-action scripts during package add or upgrade time. So, you don't
convert to IPS so much as make things work without requiring scripting in
package context.
Tools available to you to make that happen:
- Users and groups are added by actions in the IPS manifests. You
don't need to worry about these today as the OpenSolaris distribution
team takes care of translating your additions to IPS package actions.
- Similarly, driver bindings are handled by actions in IPS manifests
and today are added by the OpenSolaris distribution team.
- Manifests added or changed in /var/svc/manifest will be automatically
added as actions by the OpenSolaris distribution creation tool.
Manifests deleted will not be handled automatically today, but will
be in a shortly upcoming build. (Non-OpenSolaris-specific fix is
under review.)
- SMF services can be added (by you) to take care of file assembly or
manipulation that used to be done by a class action script or
postinstall scripts. (Obviously, if your code already has an
associated service, the assembly should be done there rather than
introducing a new service.)
These are generally the preferred solution, and you'll see a great deal
of discussion on them in the archives of this list.
These SMF services take care of assembly during boot time automatically.
If you have a need for your package to be installed or upgraded on
a running image (no packages in ON have this today), you can ask
the OpenSolaris distribution team to add an action to the appropriate
packages to have the service refreshed or restarted when specified
files are added/modified/deleted by the packaging system.
The good news about the SMF service model is that it works great for SVR4
packages too. No postinstall or class action scripts required. (If you
aren't relying on the in-package scripting for proper install/upgrade,
testing the SVR4 package itself means it will work on OpenSolaris too.)
There's plenty more to be said, of course, about specific recommendations
for specific problems. Some of those are in the archives.
liane
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
