[maemo-commits] [maemo-commits] r16459 - in projects/haf/doc: . mvo

[From: subversion at stage.maemo.org]

Author: marivoll
Date: 2008-10-23 16:01:25 +0300 (Thu, 23 Oct 2008)
New Revision: 16459

Added:
   projects/haf/doc/mvo/
   projects/haf/doc/mvo/system-model-2.txt
Log:
New.


Added: projects/haf/doc/mvo/system-model-2.txt
===================================================================
--- projects/haf/doc/mvo/system-model-2.txt	2008-10-22 15:49:06 UTC (rev 16458)
+++ projects/haf/doc/mvo/system-model-2.txt	2008-10-23 13:01:25 UTC (rev 16459)
@@ -0,0 +1,247 @@
+
+			  MAEMO SYSTEM MODEL
+			  ------------------
+
+			       Part II
+
+			       Binaries
+
+
+[ Part I of the Maemo System Model describes source code: how it is
+  stored, compiled, maintained, and released; how bugs are tracked;
+  how it is structured into domains, sub-systems, layers, and
+  components; how the Maemo system is bootstrapped from source; how we
+  import upstream sources; how we handle NMUs; etc.
+
+  This text has been written in parallel with Part I, so I had to make
+  a few assumptions about Part I that might turn out to be wrong.  The
+  assumptions are:
+
+  - We are talking about the "Maemo" system, from its Harmattan
+    version onwards.
+
+  - Maemo contains a operating system (the "Maemo OS") that runs in a
+    variety of configurations on a variety of devices.  The OS
+    includes programs, libraries, kernels, firmware, etc.
+
+  - 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
+    the "OS" module.
+
+  - Maemo contains the "Maemo SDK": the tools needed to develop the
+    Maemo OS and the add-ons: build tools, documentation tools,
+    packaging tools, image creation tools, pre-loaded contents,
+    customization package templates, etc.
+
+  - Maemo is developed by multiple 'non-consenting' parties.
+    Different parties work on different parts but they all work on the
+    single Maemo project.  Nokia is one party, the rest forms the
+    Maemo community.  Nokia gets some special treatment as the 'owner'
+    of the Maemo project, but not much.
+
+  - Sources are stored and worked on in many different ways, but they
+    all come together in the form of Debian source packages that are
+    stored in the Maemo archive.  These source packages are compiled
+    by one or more buildbots in a controlled environment into Debian
+    binary packages.  That's the interface between Part I and Part II
+    of the Maemo system model.  I assume that Debian binary packages
+    have already been introduced as part of the compilation process.
+
+]
+
+* The Maemo archive
+
+[ This section can be chapter 2 of the Maemo policy document, maybe
+  after condensing it a bit. 
+]
+
+Maemo is maintained and distributed as a collection of packages.  All
+packages, both source packages and the binary packages that have been
+compiled from them, are contained in the "Maemo archive".
+
+Packages that are not in the Maemo archive are not part of Maemo and
+are shot on sight.
+
+All packages in the Maemo archive must work well with each other and
+in all possible configurations and targets, not just the officially
+supported configurations and targets.  They do this by declaring
+appropriate dependencies and conflicts with other packages.
+
+Specifically, a package that is primarily developed for the Maemo SDK
+can not assume that it will never be a installation candidate in a
+device that runs the Maemo OS on real hardware.  If such a package
+must be prevented from being installed, the reasons need to be
+identified and expressed with dependencies and conflicts.  
+
+** Categories
+
+The packages in the Maemo archive are divided into one or more
+"Categories".  The categories are used to control uploads to and
+downloads from the archive.
+
+For example, only Nokia is allowed to upload to certain categories,
+and you need a Maemo Garage account to upload to others.  Packages in
+most categories are freely distributable in source and binary form,
+but people need to agree to a license before they are allowed to
+download from other categories.
+
+Thus, categories control publishing of packages.  A package is made
+public by moving it from a category with only
+internal-plus-subcontractor access to a category with general access
+(maybe subject to a anonymous license agreement).  This is different
+from releasing a version of Maemo.  See "Distributions", below.
+
+The categories are: nokia-free, nokia-freely-distributable,
+nokia-restricted, nokia-free-pending,
+nokia-freely-distributable-pending, nokia-restricted-pending,
+nokia-secret, extras.
+
+In detail:
+
+ - nokia-free
+
+ Packages in nokia-free are Free Software.  They are licensed with a
+ OSI approved Open Source license.  Everybody can access this category
+ freely.  Only Nokia can upload to it.
+
+ - nokia-freely-distributable
+
+ Packages in nokia-freely-distributable are not Free Software, but
+ they can be redistributed freely.  Some have source, others don't.
+ Everybody can access this category freely.  Only Nokia can upload to
+ it.
+
+ - nokia-restricted 
+
+ Packages in nokia-restricted are not Free Software and can not be
+ redistributed freely.  Access to this category is granted after
+ anonymously agreeing to a license.  Only Nokia can upload to it.
+
+ This category would be used for the packages that are now in the
+ nokia-binaries tarball that comes with the SDK, and others.
+
+ Contracts with 3rd parties would need to be written so that we are
+ allowed to distribute their binaries with the license agreement of
+ nokia-restricted.
+
+ - nokia-free-pending
+
+ Packages in nokia-free-pending are Free Software suitable for
+ nokia-free that have not been published yet.  Reasons for holding
+ back free packages from being published can be incomplete legal
+ checks and the desire to keep them a trade secret until some launch
+ event.
+
+ New packages that are destined for nokia-free could be forced into
+ nokia-free-pending instead.  Legal checks can be triggered by a new
+ package appearing in nokia-free-pending.  Packages could
+ automatically move to nokia-free once the check is complete.
+
+ - nokia-freely-distributable-pending
+
+ Packages in nokia-freely-distributable-pending are suitable for
+ nokia-freely-distributable that have not been published yet, similar
+ to nokia-free-pending.
+
+ - nokia-restricted-pending
+
+ Packages in nokia-restricted-pending are suitable for
+ nokia-restricted that have not been published yet, similar to
+ nokia-free-pending.
+
+ - nokia-secret
+
+ Packages in nokia-secret can only be accessed by Nokia and only Nokia
+ can upload to it.
+
+ - extras
+
+ Packages in extras are freely distributable.  Everybody can access
+ them.  Only people with a garage.maemo.org account can upload to it.
+
+ [ We could think about offering "extras-free", "extras-non-free",
+   etc.  This could be decided by the Maemo Community itself.
+ ]
+
+The public categories starting with "nokia" are published on
+nokia.com.  The "extras" categories are published on maemo.org.
+
+
+** Distributions
+
+Most packages in the Maemo archive are part of one or more
+"Distributions".  The distributions are used to keep different lines
+of development separate from each other.  There is a 'stable' line of
+development that has been released for general consumption and only
+receives bug fixes.  There is also a 'testing' line that contains beta
+releases for daring testers.
+
+Packages can be copied from one distribution to another in order to
+release them.  Renaming or copying a whole distribution is an
+important special case of this.
+
+[ Let's try to come up with a concrete list or scheme how to publish
+  releases.  "harmattan-devel" and "harmattan-1", "harmattan-2",
+  "harmattan-3", etc?
+]
+
+There can only be a single source package in the whole Maemo archive
+with a given name, and version; and only a single binary package with
+a given name, version, and architecture.  A given version of a package
+can be in more than one distribution at the same time, of course, but
+it must be the exact same ".dsc" or ".deb" file.
+
+** Architectures
+
+If a package needs to be compiled for different target hardware
+architectures at the same time, a new architecture needs to be added
+to the Maemo archive.
+
+** Repositories
+
+The Maemo archive is published in one or more "Repositories".  A
+repository is a directory hierarchy suitable for APT, usually
+accessible via HTTP.
+
+[ Signing of repositories.  Per-category keys?  Per uploader-group
+  keys?
+]
+
+* Installation targets
+
+The Maemo OS runs on a number of devices.  It is installed via one or
+more images that are prepared from packages in the Maemo archive (and
+nothing else).
+
+Typically, packages are 'installed' into an image by letting the
+package management tools create a root filesystem in the normal way.
+Such a root filesystem can then be maintained at run-time with the
+package management tools as well.  Some packages might be used to
+create specialized images, like the kernel image that is flashed into
+its own partition without a filesystem.  Some packages might be used
+to pre-load files into the prepared root filesystem.  These files are
+then not subject to package management at run-time, which might be
+appropriate for things like pre-loaded images and videos.
+
+The Maemo SDK runs in Scratchbox targets.  Is is installed by
+extracting a 'rootstrap' tarball into the target.  The tarball is also
+prepared from packages in the Maemo archive (and nothing else).
+
+The tools for creating the installation images and rootstrap tarballs
+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.
+]
+
+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.
+
+* Configurations
+
+- "Modules"
+- User controlled configuration