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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel