From 47bee39909a0047ee1b4b2f5c52d983653015ee2 Mon Sep 17 00:00:00 2001 From: P. J. McDermott <pehjota> Date: Wed, 18 Jul 2012 21:21:13 -0400 Subject: Rewrite multiarch task and design information. --- (limited to 'dev/todo') 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. +Goals +===== -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. [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 +[wuc-mas]: https://wiki.ubuntu.com/MultiarchSpec -- cgit v0.9.1