Danek Duvall wrote: > Stephen's blog entry is still the > canonical treatise on the subject [of these SMF service additions] > and I don't see any reason to rehash it > here for the umpteenth time.
you know, I completely agree with you. it shouldnt be rehashed here infinately.. It should be *written up as a specification*. There is a clear need for this, since multiple people have asked about postinstall support and where it is, over the past few months, I think. The write up is vague, and people get differing messages and impressions when reading this mailinglist, on what the state of things such as postinstall script support, are. Asking people to go read through 6-10 different (and possibly out of date) "discussions", when they have questions about how IPS does/is supposed to work, is unreasonable. >> 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. Unless you have a flag, "this package did something that is not reversible", the packaging system will then be implicitly making a claim "this is reversible", when it is not. A false positive, if you will. Is/Does IPS have such a flag to prevent this false positive? > 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? yes. twiki, i think it was. I believe there are others. >> 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? You're not thinking in true database terms. Install process for a database driven application, may require dba type perms, to create a schema. The running app, may populate that schema with assorted data, but may not have permission to alter the schema itself. In doing a transition to a newer version, it may be required to alter the database schema. This requires higher privs than are required in normal running of the application. > 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. It seems like you are saying is, "I dont care what is most useful to the users; this is what is synthetically 'clean' to my viewpoint, and that's what matters to me". So, I shall drop discussing this further, as non-productive. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
