On Thu, Feb 14, 2008 at 01:46:42PM -0800, Philip Brown wrote: > Okay, now perhaps we're getting somewhere :-)
If you say so. > 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'" Except that it's limited to the context of the installed system, yes. > if so... then why require it to be done through SMF at all? Doesn't have to be, really. The package could just deliver a file that some other subsystem happens to read. Using SMF means that the packaging system can have a single, simple action that can wake up an otherwise arbitrary subsystem to make it do what it needs to do. But if that subsystem wakes up on its own, then the packaging system needn't do any kicking. > What is the benefit of disallowing arbitrary postinstall scripts > directly, if you kindasorta allow them like this? The same as it's been from day 1. Stephen's blog entry is still the canonical treatise on the subject, and I don't see any reason to rehash it here for the umpteenth time. Bart also mentioned another case that can't be done properly and simply with postinstall script -- running makewhatis. If every package that delivered manpages ran makewhatis in its preremove and postinstall scripts, it'd be run hundreds of times on just about any upgrade. If we eliminate the arbitrariness of putting this into a package-associated script and just deliver the information that makewhatis needs to be run after this package is installed, then the system can coalesce all this data and do it once, at the end of the run. The same holds for the info dir update thing as well. Same with fc-cache, and many of the other things that get stuffed into the postrun monstrosity. > 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 haven't said anything about requiring a reboot. > Seems like all you have done, is just make it more complex to run arbitrary > postinstall scripts. Yes! Packaging should be about delivering data, period. > 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". Correct. If the packaging system does nothing but deliver data, then it's completely reversible. Any action taken by the software that's delivered is out of the control of the packaging system. Whether that's done by an "update" method on a service, or by any other means (say X runs and dumps a conf file in /etc/X11), it's not reversible. At least, not without a system snapshot to revert to. > BTW: your premise is false, however. The "1.0.5 system" cannot properly > comprehend the data. Only the convert script can. So what does the convert script use to read 1.0.3 data and write 1.0.5 data? Does it embed a copy of 1.0.3 and spit out some common format that the 1.0.5 code can import? If the 1.0.3 data is so simple that it can be read by a shell script, then I hardly imagine that you'd find it difficult to keep that functionality in 1.0.5. Do you have a real-life example in mind for this -- mysql or postgres or a specific webapp? > There are also permission issues. The normally running application, may > not have PERMISSION to do the modifications that the upgrade data format > conversion requires. How does the app have permissions to modify the data during normal operations, then? I would think it more likely that the UID running the package install wouldn't have perms to write to non-system directories, anyway (like root unable to write on NFS). Either way, it should be up to the software to modify its own configuration, and it should do that in a context outside of packaging. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
