On Fri, Dec 19, 2008 at 05:45:01PM -0800, Bart Smaalders wrote:
> I'm working on a write-up on how to get rid of scripting when
> moving to IPS... comments appreciated.
I posted on December 16 about just this. I prototyped the start method
for a service intended to run those SVR4 packaging scripts that can
reasonably be run that way (with proper env, and everything): CAS and
post{install, remove}.
That'd be a big hammer: blunt. But it will get the job done of
_automatically_ migrating much SVR4 package scripting, with manual
migration to less blunt solutions done asynchronously.
> The key design pattern here is to have the consumer of the
> configuration file (here, genunix) handle the old file format/location
> if the new file doeesn't exist; writing out the new file resolves the
> upgrade process and completes the self-assembly.
The consumer has to have appropriate privileges or run as the correct
UID, which usually means that an SMF service will be needed for
self-assembly. SMF service start methods are typically scripted. Thus
scripting remains, but *always* in the context of the booted image.
Note that SVR4 package scripting must support running in the context of
the booted image, which is what makes my prototype mentioned above
feasible.
> A canonical example might be /etc/security/exec_attr. Here many
> different packages contribute lines into this file. With svr4
> packages, a package's file fragments are merged in by the class action
> script i.rbac during installation or upgrade. Removal is problematic
> on uninstall and is not attempted.
>
> For IPS, the proposed solution is to have each package deliver its
> portion of this file into a separate directory, using the name of the
> package (suitably escaped, of course) as the file name. A service
> that runs at boot determines whether or not the file needs to be
> re-composited from the file fragments. This cleanly handles both
> install and uninstall.
My prototype does just that! And it re-uses SVR4 scripting where it
exists, which means: less effort is needed to port SVR4 scripting.
> The key design pattern here is to have packages deliver their
> components as files, which is something the packaging system is
> designed to do. Assembly of the composited file is left to boot time
> and an SMF service, which deals with older package fragments, etc.
Yup.
The subject line of my 12/16 post is "Automatic migration of SVR4
scripting uses to IPS -- worthwhile?"
So... is it worthwhile?
Nico
--
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
