[osol-arc] Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006]

[Bart Smaalders]

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