diff options
| -rw-r--r-- | dev/todo/multiarch.mdwn | 77 |
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 |