Re: Multiarch preparations needed for etch dpkg

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Steve Langasek <vorlon@debian.org> writes:

> On Sat, May 20, 2006 at 10:27:35PM +0200, Goswin von Brederlow wrote:
>> - 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.

Say you have a binary package (Multi-Arch: no) firfox and a
library/plugin package firefox-mplayer-plugin.

This could be handled by firefox having a "Provides:
firefox-abiXX-arch-os-libc". Apt and perl for example already provide
an abi pseudopackage.


Another example would be build-essential:

Depends: libc6-dev | libc-dev, gcc (>= 3:3.3), g++ (>= 3:3.3), make, dpkg-dev (>= 1.4.1.19)

becomes

Depends: libc6-dev:arch | libc-dev:arch, gcc (>= 3:3.3), g++ (>= 3:3.3), make, dpkg-dev (>= 1.4.1.19), dpkg:arch

Again a provides could be used to achieve the same effect.

> 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/

The changes (to dpkg) required for the new depends syntax are rather
simple. The only non trivial change is in lib/fields.c in the actual
parser.

  * Add arch specific dependencies
    + lib/fields.c: Allow ':arch' in f_dependency()
    + lib/dpkg-db.h: struct deppossi: add const char *edname
    + lib/fields.c: f_dependency(): preserve deppossi->edname
    + src/processarc.c: process_archive(): copy deppossi->edname accross
    + Use edname instead of ed->name in:
      - lib/dump.c: w_dependency()
      - dselect/pkgsublist.cc
      - dselect/pkgdepcon.cc
      - src/archives.c
      - src/remove.c
      - src/depcon.c
      - src/processarc.c
      - src/packages.c

I think we should add the new syntax for future use instead of
requiring provides for this since provides can't be versioned and
therefore have to have the versioning inside the name. Actual use of
this feature could be delayed till etch+1 or etch+2 depending on how
much time we allow for updaters. But isn't the rule that you have to
update one release at a time and can't savely omit one? Users of
etch+1 would be expected to have an etch dpkg then.

MfG
        Goswin