Danek Duvall wrote: > On Thu, Feb 14, 2008 at 12:05:44PM -0800, Philip Brown wrote: >>> END-USER-GOAL: Upgrade my-www-soft from version 1.0.3 to version 1.0.5 >>[..] >> [Danek's "new strategy example" follows] > Step 1, as above. > > Step 2, as above. One of the files that [EMAIL PROTECTED] delivers is a > service that will run upgrade_dbdata_to_1.0.5_format.sh as well as an > action in the package that says, "kick this service when you're done". > > Step 3: When the package upgrade is complete, the service is kicked > (assuming the upgrade was done on a live image; on an unbooted image, it's > delayed until next boot) > > Step 4: The service performs the reformatting. >
Okay, now perhaps we're getting somewhere :-) You seem to *imply*, although you dont actually state, "This 'service' can run anything and everything it wants to. It is basically equivalent in power/functionality to the old style 'run a postinstall script'" if so... then why require it to be done through SMF at all? What is the benefit of disallowing arbitrary postinstall scripts directly, if you kindasorta allow them like this? It's a whole lot more hassle to the packager/developer, with no benefit that I'm seeing, if they dont require a "wait until boot to run" behaviour. FYI: I've seen a lot of postinstall scripts in the last 5 years. With the exception of device driver related stuff, I cant recall even ONE, that required a "wait until reboot" behaviour. > I'm still not seeing anything that requires this to be run in the context > of the package upgrade itself. I'm not seeing anything that shows there to be a benefit of NOT running it in the context of the packaging upgrade. Seems like all you have done, is just make it more complex to run arbitrary postinstall scripts. Something that adds significantly more complexity, with no tangible benefit, should seem to fall to some kind of Occam's razor principle. Or a "K.I.S.S." one. Not to mention, that it seems... inappropriate... to force a One Time Action, to be a "service", if all you want it to do is, "run once, right now, then quit and disappear". A more general, but related note: One of the big arguments I seem to recall against allowing postinstall scripts, was: "if we limit actions, to only certain pre-configured, reversible actions, then we can guarantee that a package can be installed/removed/upgraded/downgraded with no side effects". Any such complaint, must also equally apply to this optional 'service' capability that you describe. You have no guarantee that such a service is reversible, in its actions. So, you must needs have some kind of internal flag, "this package is not cleanly reversible". [you DO plan to have such a flag, right?] Such a flag could apply to a regular style postinstall script too. So that rationale to disallow postintall scripts, would appear to be thoroughly invalidated. > I also don't see why 1.0.5 can't just run on the 1.0.3 data, since > obviously a system with only 1.0.5 can still read the 1.0.3 data, in order > to convert it. Why this is in an adjunct script instead of in the main > application, I dunno, but perhaps that's just the design choice of the > developer. Exactly. You're writing a packaging system. not something that gets to control the design decisions of software developers worldwide :-} BTW: your premise is false, however. The "1.0.5 system" cannot properly comprehend the data. Only the convert script can. Sometimes you just have to drop backward compatibility, for performance reasons. There are also permission issues. The normally running application, may not have PERMISSION to do the modifications that the upgrade data format conversion requires. This would particularly be true of well written (security-concious) web applications. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
