Re: Multiarch preparations needed for etch dpkg
Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
> 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.
After a lengthy discussion on irc Steve and I have come to the
conclusion that we don't seem to need a "Depends: foo:arch" syntax if
we instead implement versioned provides.
Afaik currently dpkg allows "Provides: foo (= 1.0)" but the version
gets ignored when resolving depends. If we change the semantics so
that version now have meaning an older dpkg will still ignore it and
potentialy install the wrong package. But it won't stop people from
updating to a newer dpkg and frontends, which then in turn can correct
the error.
I think packages with a versioned depends on a provided package will
be uninstallable with the current dpkg, right? If so that would only
mean packages in etch+1 will be uninstallable without a prior update
to a dpkg that handles versioned provides.
> 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.
Actualy strike that. libc6-dev would not be "Multi-Arch: no" because
the libc.so linker script is arch dependent. Dpkg then resolves the
depends correctly already so that libc6-dev and build-essential always
have the same architecture. Same for gcc and g++.
Only the "dpkg:arch" is required and that can be done with "Provides:
dpkg-arch" again.
>> 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.)
I now agree with that with one reservation.
For multiarch dpkg in the current WIP implementation to work correctly
no future multiarch package may be installed with the existing
dpkg. But if we get the other preparations into etch dpkg this can be
caught in preinst of dpkg and the user can be instructed to first
install etch dpkg, then reinstall affected packages. I think that is
an acceptable limitation.
So we don't have to change the syntax but we do have to change dpkg
to smooth the way ahead for etch+1.
MfG
Goswin
Reply to: