On Sat, May 20, 2006 at 10:27:35PM +0200, Goswin von Brederlow wrote: > Matt Taggart and others <taggart@debian.org> writes: > > Several people have been working on a project we've been calling "multiarch", > > to seamlessly support running applications for multiple different binary > > targets on the same system. The main example being running i386-linux-gnu > > applications on amd64-linux-gnu systems, but many other working combinations > > exist. More info on Debian's multiarch efforts at > > http://wiki.debian.org/multiarch > > Part of implementing multiarch requires changes to dpkg. > I've added another section to the wiki above listing the changes I > would like to see implemented in etch dpkg in preparation for a future > multiarch dpkg. I still think multiarch can be done in the current > dpkg, esspecialy since I have an implementation that is 90% there. > The listed changes are linked on the main page or directly under > http://wiki.debian.org/dpkg-multiarch > This comes down to 3 small changes with little to no impact on the > current system but enabling features for the future: > - Introduce the Multi-Arch field so sources can already set it > - Store meta data with an arch tag when Multi-Arch: yes is set > (Note that no package yet sets this. This is so packages can start > using Multi-Arch: yes without confusing future dpkg about file > locations.) > I propose to use /var/lib/dpkg/info/<pkg>.<arch>.install as syntax. > - Allow arch specific depends > I propose to use "Depends: <pkg>:<arch> (>= 1.2-3)" as syntax for > thses. While for etch no package should use them dpkg should accept > them so installing etch+1 debs can go without hitch. > (Note that this also impacts on apt and aptitude) Please provide a counter-example to the following assertion: A multiarch package's dependency on another package must be satisfied by a package of a particular (i.e., of the same) architecture IFF the depended-on package is also a multi-arch package. If you don't have any counter-examples to this claim, then it's my belief that the last of these changes is not required, because versioned dependencies are enough to ensure the dependency is not incorrectly satisfied by a non-multiarch version of the package, and Multi-Arch: yes flags on the new versions of the package give dpkg & front-ends enough information to correctly determine whether the dependency is properly satisfied and to resolve the dependency if not. I believe this removes the need for a backwards-incompatible syntax change to the Depends: field, which is an objection I had to the posted dpkg v2 multiarch proposal as well. (Note that without this change to Depends: syntax, any of these "multiarch" packages can be installed fine on the native architecture with the existing dpkg, but that with this syntax change users must first upgrade to a new set of packaging tools before these package relationships are parseable.) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature