I know that for most people who have been following along for a while, even if intermittently, this is all a re-tread, but those who haven't checked in for a couple of years, or are new to the project or the distribution might appreciate a refresher, so please bear with me as I go over the basics again.
The number one reason that we're not allowing it is because it's very hard to get all the possible install contexts correct. This is the lead argument in Stephen's blog entries back in 2007, and while the points you raise about reversibility is valid, but we decided years ago that this would be handled by ZFS, not the packaging system. The packaging system cannot roll back arbitrary change made to the system once outside code has gotten its hands on it, but with the appropriate use of ZFS snapshots, the system can. Note that getting scripting wrong is not (just) a matter of laziness on the part of the script writer. You can be a very diligent script writer and still have the package be completely useless when the OS changes and suddenly there's a new install context. Say, zones. Few postinstall scripts that did anything interesting worked properly in zones. Like installing a driver? Not so much. Or think about the introduction of split root/usr packages -- / is installed in one place, /usr in a completely different place. There's no way to anticipate that kind of thing ahead of time, so when it's introduced and actually used, your package is busted. The other common and potentially unavoidable scripting mistakes are similar -- the use of some technology that doesn't exist in the miniroot or other minimized install-time environment (Java is one example from a long time ago), or forgetting about $PKG_INSTALL_DIR and all the variations when installing a package to a different root directory. And having to work around limitations in the underlying OS tools that would allow you to add, say, users to a filesystem not mounted at /. Implementing useradd in /sbin/sh? Yum. Now, none of that precludes scripting itself, just the point at which it's run. What we've done is moved that to a time when the system is fully assembled, and booted. If you're installing a package on a live system, then it's ready to go after the packaged bits are down. If you're installing a package onto a system which isn't live (mounted somewhere else, possibly in pieces, or in some brand new context you couldn't possibly have imagined a year or two ago), then the script will be run at the time the system boots. You don't need to have a self-destroying SMF method just to do this, though you certainly can do so. The RBAC example is one where the OS already provides such a service. Place the fragment of foo_attr in foo_attr.d with a unique name, and system/rbac will assemble it into the main file for you. When the file is removed, the service will remove the fragment from the main file. We don't yet have services for the other files, but you're more than welcome to write them and submit them. In some cases, it makes sense to have the application do the work itself -- the cron implementations on Linux have for some time now supported directories filled with jobs in scripts, and that's something we probably should emulate. Users and groups (and drivers) are handled directly by the packaging system; the first two are needed simply to create filesystem objects, and the latter are needed for booting. There may be other things that require the filesystem to be updated before SMF is up and running, but so far we haven't gotten many (if any) requests for such things. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
