From d50838e9924c069977b9b4f0815aecfb7cbcddb7 Mon Sep 17 00:00:00 2001
From: P. J. McDermott <pehjota>
Date: Thu, 05 Jul 2012 01:21:59 -0400
Subject: Add Multiarch project to wiki.

---
(limited to 'dev/todo')

diff --git a/dev/todo/multiarch.mdwn b/dev/todo/multiarch.mdwn
new file mode 100644
index 0000000..4bf5413
--- /dev/null
+++ b/dev/todo/multiarch.mdwn
@@ -0,0 +1,77 @@
+[[!meta title="Multiarch"]]
+
+Multiarch refers to the ability to install and use packages built for non-native
+architectures.  It is currently being [documented and implemented][wdo-ma] in
+Debian and Ubuntu.  Multiarch is useful for this distribution because it makes
+cross compiling easy (see "Package Cross Building Tool" and "Multiarch Cross
+Toolchain Packages").
+
+Simply speaking, there are six [aspects of a multiarch implementation][ma-des]:
+
+  * **Filesystem Hierarchy**
+    
+    To accomodate simultaneous installation of shared libraries built for
+    different architectures, library paths are suffixed with a directory name
+    that identifies a particular architecture.  For this distribution, that
+    directory name will be the name of the binary architecture; for example,
+    library paths for the `cortexa8-linux-eglibc` architecture will be
+    `/lib/cortexa8-linux-eglibc` and `/usr/lib/cortexa8-linux-eglibc`.
+    
+    The toolchain (especially the dynamic linker) needs to be configured to use
+    these library paths.
+
+  * **A `Multi-Arch` Control Field**
+    
+    A `Multi-Arch` control field specifies how a package can satisfy
+    dependencies of other packages.  A value of `same` means that a package can
+    only satisfy dependencies of packages built for the architecture for which
+    it was built.  This is useful for shared libraries, which can only be
+    dynamically linked against binary objects built for the same architecture.
+    A value of `foreign` means that a package can satisfy dependencies of
+    packages built for any architecture.  This is useful for utility programs,
+    which can be used by software built for any architecture.
+    
+    The package manager (opkg in our case) and package building tools
+    (specifically oh-checkbuilddeps of opkhelper) must be able to understand
+    and use this field in resolving package dependencies.
+
+  * **Architecture Specification in Package Relationships**
+    
+    Control fields like `Depends` are extended to support an architecture
+    specification of either `any` or `same`, allowing a package to specify
+    whether or not it needs a package of the same architecture.  The dependent
+    package has a `Multi-Arch` field with value `allowed`.
+    
+    The package manager and package building tools must be able to understand
+    and use this architecture syntax in relationship fields.
+
+  * **Handling of Packages with `Architecture: all`**
+    
+    Dependence on packages installable and usable on any architecture
+    (especially considering opkg's ability to install packages of multiple
+    architectures) must be researched.
+
+  * **Non-Library Files in Library Packages**
+    
+    Library packages provide files outside of system library paths, such as
+    configuration and package documentation files.  A solution must be designed
+    to allow a package built for one architecture to be co-installable with the
+    same package built for a different architecture (or to determine if they are
+    co-installable at all).
+
+  * **Ability to Install Packages Built for Non-Native Architectures**
+    
+    The package manager must be able to install packages built for multiple
+    architectures (the whole point of multiarch).  Fortunately for us, opkg
+    already handles this.  The `arch` option in `opkg.conf` [allows the user to
+    specify architectures][opkg-conf-arch] for which packages can be installed.
+
+In summary, there is much design work to be done, opkg and opkhelper must be
+modified to support multiarch, and certain packages will need to be built to
+handle multiarch library paths.  Of course Debian is a great reference
+implementation, but there still remains much original work to be done.
+
+
+[wdo-ma]: http://wiki.debian.org/Multiarch
+[ma-des]: https://wiki.ubuntu.com/MultiarchSpec#Design
+[opkg-conf-arch]: http://wiki.openwrt.org/doc/techref/opkg#adjust.architectures
--
cgit v0.9.1