Liane Praza wrote:
...
> 
> 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.

Good!

> 
> - 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.)


It seems kind of like overkill to have to create an entire SMF manifest
to replace what 5 or 10 lines of shell script used to do.  Are there
any libraries or generic methods that can be used to make the
changes needed?  Mostly I'm talking about making edits to various
system files.

> 
>   These are generally the preferred solution, and you'll see a great deal
>   of discussion on them in the archives of this list.


Yes, but I have yet to see a definitive procedure for attacking the problem,
most of the archive discussions are full of "possible solutions", but I can't 
find a clear-cut description of how developers should proceed with the migration
to IPS.   There really needs to be a big section in the OpenSolaris IPS area
describing exactly how one migrates an SVR4 package to IPS.  One that includes
examples that fall outside of the SMF model because there are a lot 
of packages in ON today that will fail when the switchover happens because
they don't fit the preferred IPS + SMF model.


>   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 package I am working on does not have an SMF manifest, it is installing
a driver and the postinstall needs to update a system file in /etc.  There are
a bunch of "i.foo" files in the current SVR4 "common_files" area that are not 
addressed by SMF or other methods - what is the plan for migrating all of the 
packages
that fall outside of the scenarios that you have described?


> 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.


It would be nice if the mailing list archives were searchable (I really prefer
the JIVE forums) but that is a separate issue entirely.

-Wyllys
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to