James Carlson wrote: > Bart Smaalders writes: >> You mean like gnome's configuration info? > > An excellent example, I think. See CR 4808196. > >> Configuration info needs to be owned by the app and edited by >> the app, I think. > > That certainly reduces the number of accurate parsers needed, but it > likely increases the difficulty of upgrade. In order to upgrade, you > need an application that can run on the oldest system to be upgraded > (as well as the current one) and parse the oldest version of the > configuration file. > > One of the attractions of plain old text files is that the upgrade > process can trust that basic text tools such as awk are present and > can run a script that we design in the future to manage that > transition. >
Yes, and that upgrade process needs to be modified every time we add a new form of upgrade: diskless, zones, virtualization, .... Writing package and patch scripts is becoming more and more difficult as we add additional installation contexts.... It seems a lot more sensible to mimic what the ZFS folks do - they make the ZFS modules handle updating on-disk format, and don't expect the upgrade process to do it for them. Installation/upgrade should be about updating the files on the disk; coping w/ old/merged config files can be deferred until the new instance is up and running. If that's not the case, the config info storage should be redesigned so that is possible. > If we're talking about compiled applications instead of scripts, we > need to be compiling those _new_ applications on the oldest systems we > support so that the binaries that perform the upgrade actions will run > on the systems we want to upgrade, and thus just forget about using > new OS features. (Or, alternatively, we just abandon the concept of > LU.) > > TANSTAAFL. > Have the app handle the upgrade once it's running, ala firefox. _ Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
