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".
Well, that would certainly be very nice; However, in the real world, not all
software is written that way :-)
Do you want a packaging system that only works well with 95% of software out
there, or do you want a packaging system that works with 99% of software?
You may say that 95% is good enough. My perspective, is that it's the 4%
difference, the "tricky" software packages out there, are the ones that
people *most want handled for them* !
Now, to go back to my example of one of the "tricky" packages, in more
detail :-)
I'll attempt to make it highly detailed.
This is the way that, in my opinion, things would work, to give the user the
most pleasant upgrade experience.
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]
> If the data format is sufficiently volatile that it's not cost-effective
> for the software developer to do this, then the burden is shifted to the
> end-user, who has to deal with a more complicated upgrade procedure,
> possibly including hand-holding by 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)
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.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
