Onion Information

Page Clicks: 0

First Seen: 03/11/2024

Last Indexed: 10/22/2024

Domain Index Total: 71

Skip navigation . Multiarch - An a proposal and an implementation Proposal details: Abstract: Since the debian-amd64 port started, there has been rumors and half-way implementations of a hybrid system which supports both i386 and amd64 packages. This was first known as biarch then multiarch. Multiarch is an implementation of a Debian system which exploits the possibilities inherent to architectures (used in the Debian sense) such as amd64, sparc and Nienna, better known as "Debian NetBSD". It allows the system to have .debs for multiple architectures installed in a sensible way (meaning not separate chroots, for instance) and a way to express trans-architectural dependencies. The multiarch proposals have been floating around for a long time now and they were discussed fairly heavily at the last Debconf. As part of my master's thesis, I am doing an implementation of a partly-multiarched system. It shows that it is both possible to do a multiarched system as well as outlining some of the issues that will crop up. As such, the proposal has two parts. One is mostly-agreed on, the other is more contested. The parts are the file system implementation and how to implement this in dpkg and Debian packages. The file system implementation only speaks of libraries and library packages as those are the most interesting to make multiarch capable. Other packages which might be multiarched is the toolchain, since it has good support for coinstallations already, but having multiple installations of coreutils or sed does not really make any sort of sense. For libraries, they will install their files in /lib/$(gcc -dumpmachine) or /usr/lib/$(gcc -dumpmachine) as appropriate. gcc -dumpmachine outputs a string similar to i486-linux, x86_64-linux. For programs wanting to be multiarched, applying a transformation similar to what gcc use would probably be the right way. (gcc becomes x86_64-linux-gcc and so on.) On the packaging side of things, there are currently two proposals. One by Tollef Fog Heen (with input from different people on Debian mailing lists) and one by Anthony Towns. Both proposals means splitting packages is necessary, as files common to multiple architectures would cause overlap (think /usr/share). The proposal which is implemented here is Tollef's. It implies extending the semantics of a Depends field from what it is today where | Package: fruits | Depends: banana | Architecture: i386 means "needs a banana package installed" to "needs an i386 banana installed". | Package: fruits | Depends: banana:any | Architecture: i386 on the other hand means "I just need a banana package installed, I do not care about the architecture". The talk will concentrate around the issues which pops up when such changes are made, the needed change to infrastructure and core utilities such as dpkg. About the author: Tollef Fog Heen is a Debian Developer and has been since early 2001. He has been involved in a lot of different Debian projects from rejuvenating the debian-installer project to general package maintainance and porting work on the AMD64 port. He has been working on multiarch since early 2004. Presentation type: Talk (45 min) Track: Technical Status: Accepted Authors: Tollef Fog Heen Files: Debconf 5 Powered by COMAS , the Conference Management System by CONSOL