Danek Duvall wrote: > On Thu, Feb 14, 2008 at 10:30:58AM -0800, Philip Brown wrote: > >> It seems like you are limiting your view, to OS level "databases". >> What about actual "databases", or "database-like" applications that may be >> packaged, that may benefit from database-specific postinstall type actions? >> Or, database-USING applications. >> >> For example; some web application that uses a database; When upgrading from >> version 1.0.3, to version 1.0.5, it is required to run >> "upgrade_from_old_ver.sh", otherwise, the application becomes >> non-functional, or worse yet, corrupts the data. > > It sounds like this is a case where both 1.0.3 and 1.0.5 need to be on the > system at the same time, so that upgrade_from_old_ver.sh has access to both > the old bits and the new bits, yes?
no... that's why I said "upgrade". The script has access to the old *data*, in the untouched back-end database. but "version 1.0.3 bits" will not exist any more on the system. Would you like to re-reply to my original message, with that context? I think it would make more sense for me to wait for an updated reply from you in that reguard. >> I personally dont see that as any big advantage over "run a postinstall >> script". And I actually see some disadvantages. > > What are those disadvantages? I think that my "upgrade" example, might be a good example to follow for this. > You're right that the Oracle 15.0 package would have a fresh script to > upgrade all your Oracle 14.x databases correctly, but like I said above, I > think that's the wrong way of tackling that particular kind of problem. 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? _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
