Brian Gupta writes:
> What the technical limitations are that are in place that would prevent me
> from installing a package cluster, that brings me up to the next version of
> Solaris?
> 
> I think it would make upgrade simpler if instead of requiring a seperate
> partition, we could do it directly on the filesystem.

I assume by "separate partition," you're actually referring to Live
Upgrade's requirement to use a separate root file system on a separate
disk slice for an alternate boot environment when doing an upgrade.

The technical limitation is that you can't let go with both hands at
once and still avoid smacking into the ground.  ;-}

If you were to start replacing binaries on a running system, you'd end
up with a system that is self-inconsistent at times.  For instance,
suppose you have executables "foo" and "bar" that both use library
"libbaz," and that there are incompatible changes in the interfaces
(allowed with private libraries).  If you update libbaz first, then
both foo and bar are potentially broken until updated.  If you update
foo first, then it's broken until libbaz is updated, and once that
happens, bar breaks.

The packaging system uses rename to put the binaries in place (it
doesn't just open the file and write), so it won't cause running
binaries that have already loaded their libraries to fall from the
sky, but many other operations are unpredictable in nature:

  - Executables that are lazy-loading libraries may not yet have
    hauled a copy into memory.  If they later attempt to do this,
    after the upgrade has happened for that library but before the
    application has been restarted, then they'll die.

  - Scripts in packaging can be invoking utility programs (such as awk
    and friends) that may well be in the process of being updated as
    well.

  - Applications may depend on non-executable information, such as
    configuration files and data repositories, that may be altered or
    just removed during the upgrade process.

In other words, you're marching directly towards arbitrary and
unpredictable system failure if you do that.  I realize that other
operating systems do this as a routine matter of course, but allowing
application failure (particularly _unpredictable_ failure modes) is
not something that we have (at least historically) permitted in Sun
products.

I'm not sure that it's a good thing for OpenSolaris, either, even if
the resulting push-button upgrade mechanism seems snazzy.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to