On Fri, Feb 08, 2008 at 12:49:21AM -0500, Dennis Clarke wrote:
> Where do we stand wrt pre-remove and post-install scripts ?
Still not going to happen. IPS will not execute arbitrary code delivered
by a package, except in the case of a severe security bug.
It appears that the vast majority of postinstall scripts and class-action
scripts exist to update databases (like the various driver-related files,
/etc/passwd, and so on).
For the databases that are required for correct images, or for booting,
there will be custom actions, such as the driver (already available) and
user (in progress) actions.
For the databases that aren't needed until later in boot, we're proposing
that whatever component utilizes the database should provide a directory
where files can be placed, and an SMF method which, on start / refresh
(potentially kicked by a generic "kicker" action in the package manifest),
import the new files in that directory into the database. This has the
following advantages:
- There is precisely one execution context for the bulk of these methods
-- the current, running system, before any of the data is needed. This
eliminates all the hassles you currently have to deal with when the
running system and target system may have different architectures,
different OS releases, different filesystem mountpoints, different
tools installed, etc.
- The packaging system is reduced as far as possible to simply delivering
files. Addition of a file to a directory signals that something needs
to be added to a database, removal of a file indicates that something
needs to be removed, and update of a file indicates that something
needs to change. The simplest mechanisms can merely rebuild the
database from scratch.
- Packages delivering such data can now depend on a core package
delivering the service that updates the database, rather than carrying
around what's potentially a stale script. Or they can even choose not
to depend on that package, allowing someone to install the service
after much of the data is already installed.
None of this is to say that this can't be done, or at least approximated,
with the current system, but we believe that this is much simpler, cleaner,
and more foolproof, leading to easier package development, a less anxiety-
ridden install and upgrade experience, and fewer irate users and the
resulting customer calls. Happy software comes from happy developers. :)
Now, there do exist some particularly grotty scripts out there. If there
are ones that don't fit into this model, please highlight them, 'cause we
will need to take care of them one way or another. And if you'd like to
start identifying the databases that will need this treatment, proposing
the specifics of the solutions for them (or even contributing code), please
step up.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
