path: root/dev/todo
diff options
authorP. J. McDermott <pehjota>2012-07-18 21:21:13 (EDT)
committer P. J. McDermott <>2012-07-18 21:21:13 (EDT)
commit47bee39909a0047ee1b4b2f5c52d983653015ee2 (patch)
tree6c939ebb8d7243d01ab04109ba1e3b6a4c1e529e /dev/todo
parent57216ea8bc36ff14eba064a090885b354270f7b4 (diff)
Rewrite multiarch task and design information.
Diffstat (limited to 'dev/todo')
1 files changed, 18 insertions, 63 deletions
diff --git a/dev/todo/multiarch.mdwn b/dev/todo/multiarch.mdwn
index 4bf5413..2f34940 100644
--- a/dev/todo/multiarch.mdwn
+++ b/dev/todo/multiarch.mdwn
@@ -1,77 +1,32 @@
[[!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").
+architectures and the ability to coinstall multiple architecture builds of any
+supporting package.
-Simply speaking, there are six [aspects of a multiarch implementation][ma-des]:
+It is currently being [designed][wuc-mas] and [implemented][wdo-ma] in Debian
+and Ubuntu. Multiarch is useful for this distribution because it can make cross
+building and cross installing easy.
- * **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.
+Design Aspects
- * **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.
+There are three high-level design aspects to this multiarch implementation: the
+filesystem hierarchy that primarily enables package coinstallability, control
+information documenting package coinstallability and dependency satisfaction,
+and coinstallability considerations in package management.
- * **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.
+For more details, see the [[multiarch_design_document|dev/multiarch/design]].
- * **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.
+The design and implementation of the filesystem hierarchy is
+[[a_goal_for_release_1.0.0|dev/releases/1]]. Package coinstallability is not a
+goal for this release.