Danek Duvall wrote: > > 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).
It seems like you are limiting your view, to OS level "databases". What about actual "databases", or "database-like" applications that may be packaged, that may benefit from database-specific postinstall type actions? Or, database-USING applications. For example; some web application that uses a database; When upgrading from version 1.0.3, to version 1.0.5, it is required to run "upgrade_from_old_ver.sh", otherwise, the application becomes non-functional, or worse yet, corrupts the data. > 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. To make sure I'm understanding what you are saying; it seems like you are suggesting a varient on the old hack of, "new program provides /etc/rc3.d/S99runmeonce", except that rather than dropping a file into /etc/rc3.d, you are saying they now need to put it in the new init framework, aka SMF. I personally dont see that as any big advantage over "run a postinstall script". And I actually see some disadvantages. I read your summary of advantages for this; however, I think you are oversimplifying things, and not allowing for easy software management for the user in complex cases, where the people doing the software packaging are actually intelligent enough to write good scripts. In other words; what you have stated, works great for simple cases. But it fails for complex cases, if you dont allow for arbitrary execution. (it wasnt quite clear to me, whether your "put stuff in SMF" writeup, included a more liberal allowance for arbitrary code, or not. > This has the following advantages: > [...] > - 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. This paragraph was confusing to me. The "stale script" part, did not seem to follow a normal cause and effect chain. New upgrades/data, REQUIRE NEW scripts to handle the upgrades/data. Seems as though it is more likely that the new package, will have the newer (and thus up to date) script, rather than a stale script. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
