On Thu, Feb 14, 2008 at 12:05:44PM -0800, Philip Brown wrote: > Danek Duvall wrote: > > >> well, oracle is a huge horrible complex beast, that always seems to > >> require > >> more handholding than one might think. > >> What about things considerably less complex than oracle, though? What do > >> you > >> think the "best" way of handling that sort of thing is? > > > > The best way is always going to be that the software responsible for > > managing the data is capable of reading old formats for some period of time > > after it stops writing those formats by default, and either doing an > > automatic conversion, or allowing the customer to decide when that > > conversion happens -- should they ever wish to downgrade, or the data is > > shared between systems that might have different revisions of the database > > software. See ZFS for one example of where this works quite smoothly. > > You seem to be saying, "'properly' written software, should never even see > this as an issue; it should just behave well in all circumstances".
You asked for the best way of handling such a thing, which was precisely what I responded with. > END-USER-GOAL: Upgrade my-www-soft from version 1.0.3 to version 1.0.5 > > USER ACTION: [run "upgrade my-www-soft" command. go have a coffee] > > SYSTEM ACTIONS: > 1. remove my-www-soft v1.0.3 binaries/scripts/.... from filesystems, > with the exception of a config file specifying, > "here's the database configuration, for my back-end database" > > 2. pull down my-www-soft v1.0.5 binaries/scripts and add them to > the filesystem > > 3. Do some kind of check: hey, need to run conversion script for this > install: it's an upgrade!!! > > 4. run upgrade_dbdata_to_1.0.5_format.sh > > 5. "install complete" > > USER ACTION: [returns from coffee break: oh good it's done, now time to do > some actual useful work, rather than mucking with trivialities of upgrading > by hand] 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. Step 5, as above. I'm still not seeing anything that requires this to be run in the context of the package upgrade itself. 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. > In my opinion, a good package maintainer, shifts as much of the > "complication" of upgrade procedures as possible, from the user, to > themselves. (and the same can be said of install procedures, of course) Sure. > If you do not allow arbitrary script execution, then you limit the package > maintainer's ability to do that. You thereby limit their effectiveness as a > package maintainer. Again, give me an example which requires arbitrary scripts to be run in the packaging context. You can make this claim all you want, but without any data to back it up, you have no argument. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
