[maemo-commits] [maemo-commits] r16554 - projects/haf/doc/mvo

[From: subversion at stage.maemo.org]

Author: marivoll
Date: 2008-11-01 23:12:50 +0200 (Sat, 01 Nov 2008)
New Revision: 16554

Modified:
   projects/haf/doc/mvo/system-model-2.txt
Log:
Pruning of in-line comments.  Typos.


Modified: projects/haf/doc/mvo/system-model-2.txt
===================================================================
--- projects/haf/doc/mvo/system-model-2.txt	2008-11-01 20:28:21 UTC (rev 16553)
+++ projects/haf/doc/mvo/system-model-2.txt	2008-11-01 21:12:50 UTC (rev 16554)
@@ -27,7 +27,7 @@
   - Maemo contains applications, plugins, theme graphics and other
     optional add-on "modules" that run on the Maemo OS or enhance it.
     The current "Extras" repository is part of Maemo, for example, and
-    applications like the Browser or EMail are not necessarily part of
+    applications like the Browser or Email are not necessarily part of
     the OS module.
 
   - Maemo contains the "Maemo SDK": the tools needed to develop the
@@ -59,6 +59,18 @@
   fully: storing the package lists that define a distribution in a VCS
   and use VCS operations to maintain them.
 
+  Most of this is modeled after Debian, of course.  The significant
+  differences are:
+
+  - There is no "unstable".
+
+  - We release "modules", not a whole distribution.  Modules are
+    prepared in "testing" until they are ready to be copied into
+    "stable".
+
+  - Upload and download rights are more complicated since
+    unfortunately not everyone is equal in the land of Maemo.
+
 ]
 
 * The Maemo archive
@@ -173,7 +185,7 @@
  Packages in harmattan-stable should be installable: all their
  run-time dependencies should be available, among other things.
 
- Packages in harmattan-stable should be rebuildable: all their build
+ Packages in harmattan-stable should be compilable: all their build
  dependencies should be available, among other things.
 
  - harmattan-testing
@@ -224,26 +236,24 @@
 These problems need to be solved by simply computing the correct
 run-time dependencies during build time.
 
-[ In other words, problems will arise when the interface management is
-  too conservative.  We will make unrelated packages suffer in order
-  to find these flaws, but I think it is worth it.  Putting such a big
-  responsibility on interface management is a good thing, IMO, and I
-  am confident that all flaws can actually be fixed.  We will be
-  forced to get a very firm grip on the compatibility between one
-  release and the next.
-  
-  As a concrete and very relevant example, consider dpkg-shlibdeps and
-  friends.  This is the machinery that computes the ${shlibs:Depends}
-  substitutions that are used to automatically pick up the right
-  dependencies on shared library packages.
+A concrete example might be in order: a program in package P linking
+against a shared library in package L.  The harmattan-stable
+distribution contains version 0 of L (L0), and harmattan-testing
+contains L1.  P is compiled in harmattan-testing against L1 but then
+installed in a harmattan-stable installation where only L0 is
+available.
 
-  This is done by having the tools take a close look at the symbols
-  that are actually used from the shared library.  Then the lowest
-  version of the library is found that exports that set of symbols.
-  In this way, the run-time dependencies are very accurate and not too
-  conservative.  We should take this system into use.
-]
+One might expect that compiling P against L1 will cause it acquire a
+dependency of the form "L (>= 1)".  This would prevent it from being
+released to harmattan-stable, which only contains L0.  This is the
+correct behavior when P uses symbols of L that are not available in
+L0.  P has to wait until L1 is released.
 
+However, when P only uses symbols that are available in L0, the
+correct dependency is "L (>= 0)".  Our tools and packages will not
+currently figure this out and will produce the incorrect "L (>= 1)"
+dependency.  Some effort is needed, and would be well spent.
+
 *** Integration snapshots
 
 A "integration snapshot" is short-lived distribution that has been
@@ -251,7 +261,7 @@
 typically done to test the result of integrating a new set of packages
 into some distribution without actually doing it.
 
-At the point of creation a intergration snapshot is defined by a list
+At the point of creation a integration snapshot is defined by a list
 of distributions, plus a list of packages to take from each
 distribution.  It is never modified after creation.
 
@@ -292,18 +302,9 @@
 empty.  The harmattan-stable distribution is automatically frozen
 whenever harmattan-proposed-updates is non-empty.
 
-[ That is, we use locking to avoid conflicts here, like pre-CVS
-  revision control systems.  This is appropriate for high-priority,
-  urgent updates, I'd say.
-]
-
 Care must be taken that the changes that enter harmattan-stable via
 harmattan-proposed-updates are also included in harmattan-testing.
 
-[ Fixes on your release branch must be included in your development
-  branch as well.
-]
-
 *** Continuity
 
 The Maemo archive can and should contain the distributions for
@@ -403,11 +404,6 @@
 are contained in the Maemo archive and are maintained like any other
 component.
 
-[ I hope we are rid of Scratchbox devkits and toolchains in Harmattan.
-  I think that the Maemo SDK+ is still much too complicated with too
-  much magic, but that's a separate discussion.
-]
-
 Both the Maemo OS in a device and the Maemo SDK in a Scratchbox target
 are maintained by installing packages from the Maemo archive and
 removing already installed packages with the package management tools.
@@ -424,21 +420,15 @@
 However, the Browser can also be released independently inbetween OS
 releases.
 
-[ This is different from Debian, where the whole of testing is
-  released as a unit.  We don't do that since we want to release
-  'modules' independently.
-]
-
 When copying a group of packages in this way, the harmattan-stable
 distribution must not break, of course.  Most run-time and build-time
 dependencies between packages should still be satisfiable, and those
 that break should be identified and the breakage approved.
 
-[ Breaking harmattan-stable might be considered OK when we release a
-  OS version that is incompatible with a 3rd party application.  Such
-  an application should ultimately not be able to delay the OS
-  release.  This should be the exception and not the rule, of course.
-]
+Breaking harmattan-stable might be considered OK when we release a OS
+version that is incompatible with a 3rd party application.  Such an
+application should ultimately not be able to delay the OS release.
+This should be the exception and not the rule, of course.
 
 A integration snapshot can be used to test how the new
 harmattan-stable would look like.  It would be made from all packages
@@ -452,14 +442,10 @@
 of the Browser should not be surprised by a new version of the OS
 suddenly appearing in harmattan-stable.
 
-[ In other words, we must detect conflicts and merge the new changes
-  until the conflicts are gone, like with CVS, Subversion etc.  
-]
-
 Note that the SDK does not need to be released: harmattan-testing _is_
 the SDK distribution.  However, SDK packages should be copied to the
 harmattan-stable distribution as well so that that distribution is
-always self-contained and recompilable.  This is part of the "do not
+always self-contained and compilable.  This is part of the "do not
 break harmattan-stable" rule: The harmattan-stable distribution is
 also considered broken when its packages can not be recompiled.  This
 is important when using harmattan-proposed-updates for urgent updates.
@@ -467,7 +453,7 @@
 ** Upgrade chaining
 
 Some modules are only supported to be upgraded on top of the
-immediately preceeding released version of that module.  People should
+immediately preceding released version of that module.  People should
 not be allowed to skip released versions when upgrading.
 
 Forcing a chain of upgrades like this can be done by creating a new