Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)

[Erik Garrison]

On Mon, Jul 14, 2008 at 10:05:46AM -0400, Daniel Drake wrote:
> On Mon, 2008-07-14 at 09:14 -0400, Greg Smith wrote:
> > - Leaving aside how its done technically, I believe that Linux 
> > distributions are fully backward compatible. That is, you can go to the 
> > latest supported Distribution and leave your Firefox (or any 
> > application) on its older release and it will still work fine. Let me 
> > know if that is not correct. I think that is what we need to strive for, 
> > eventually.
> 
> "Upgrading a distribution" is a very broad thing indeed. There are many
> components and considerations involved.
> 
> I'm unable to think up any specific examples, but in general I think I
> disagree with your statement. Software that runs on one version of a
> distribution will be dependent on components which get upgraded/removed
> during the distribution upgrade, so in the end that piece of software
> will end up not working.
> 

I disagree as well.

Applications are fundamentally embedded within the system in which they
run.  This is particularly true within in the free / open source
software environment in which our work is grounded.

In such distributions, a specific version of a given application
typically relies upon version ranges of various software libraries.
These libraries encode systems which are required by the application but
which are general enough that they may be used by multiple applications
for different ends.  Sharing code in this manner yields savings in terms
of developer time and disk space, but it introduces a complex software
dependency management problem.

In practice, the complex interdependencies which arise due to this
pattern of code sharing have encouraged the development of applications
(the package managers) which automatically manage system upgrade and
software installation by resolving dependencies between software
packages.  And in turn, the use of these systems has encouraged the
process of code sharing by making commonly shared software libraries
more accessible to developers.

As Daniel notes, the package manager is the core software management
entity in a typical distribution:

On Mon, Jul 14, 2008 at 10:05:46AM -0400, Daniel Drake wrote:
> This is possible for distributions because both firefox (the
> application) and it's dependencies (underlying libraries etc) are all
> under control of one entity: the package manager. This isn't true in our
> case, where libraries are controlled by the rpm/yum package manager, but
> applications (activities) are not.

... Yet the barrier we have established between system and application
prevents our utilization of such a system for software distribution
management.

We have attempted to structure our system such that applications are
independent from the underlying operating system.  We desire this
distinction because it purportedly allows us to modularize user-level
software systems into discreet non-interacting bundles, yielding
benefits for system security and software distribution.

In return for these benefits we must manage an optimization problem
whose solubility decreases in step with the number of potentially useful
activities developed for the XO.  We must decide which libraries should
be pulled from application-bundle into the system, and which should be
pushed out of the system and into applications.  Additionally, we must
implement our own schemes to inform users of application / system
compatibilities.  (Note the concurrent thread on Activity versioning on
the devel list.)  We further isolate ourselves from our upstream
distributions by requiring that every application be ported to our
software distribution schema.  We incur costs in creating our own
custom solution to the problem of package management which handles
software on one side of the application / system barrier.

Erik