summaryrefslogtreecommitdiffstats
path: root/dev/todo
diff options
context:
space:
mode:
authorP. J. McDermott <pehjota>2012-07-05 01:21:59 (EDT)
committer P. J. McDermott <pjm@nac.net>2012-07-05 01:21:59 (EDT)
commitd50838e9924c069977b9b4f0815aecfb7cbcddb7 (patch)
tree3163adca472af09d70fe0c9c05a648f36bb6605d /dev/todo
parent455d2670313571ed6364b8fa99ef85a808b86123 (diff)
Add Multiarch project to wiki.
Diffstat (limited to 'dev/todo')
-rw-r--r--dev/todo/multiarch.mdwn77
1 files changed, 77 insertions, 0 deletions
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