Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?
On 09/29/2015 10:13 PM, Christoph Biedl wrote:
> Jakub Wilk wrote...
>
>> * Christoph Biedl <debian.packages.hhqj@manchmal.in-ulm.de>, 2015-09-29, 20:09:
>>> A Source package builds two "Architecture: any" packages, one "Multi-Arch:
>>> same", the other "Multi-Arch: foreign". The first has a strict versioned
>>> relationship on the second:
>>>
>>> | Package: ma_same
>>> | Architecture: any
>>> | Multi-Arch: same
>>> | Depends: ma_foreign (= ${Source-Version})
>>
>> Don't use ${Source-Version}. This variable is deprecated, because the name
>> is misleading. It is actually equivalent to ${binary:Version}.
>
> *ouch* Of course. I always use ${binary:Version}. Sorry for the mess,
> must have picked this string from some weird place when preparing the
> message.
>
>>> Now I remember lintian's "not-binnmuable-all-depends-any" warning where
>>> it's recommended to relax a strict dependency all->any in order to allow
>>> binNMUs ... and I think this is basically the same scenario: ma_foreign
>>> might be installed in a different architecture than ma_same, and then any
>>> binNMU will cause havoc.
>>
>> Well, MA:same packages have to be binNMUed in sync preserve their cross-arch
>> co-installability, so the dependency is not an issue in this case.
>
> I don't follow. Assuming the following installation:
>
> Name Version Architecture
> +++-================-==========-============
> ii ma_same:amd64 5.25-3 amd64
> ii ma_foreign 5.25-3 i386
>
> Now if the package gets binNMU'd in i386, ma_foreign:i386 is available
> in version 5.25-3+b1 only. The resolver could kick ma_foreign:i386 and
> install ma_foreign:amd64 instead then, so no havoc. Appearently apt
> does this when using "apt-get dist-upgrade" - but is this desirable?
Is the ma_foreign package available on every arch (it should be if it is
a real Architecture: any package) and is amd64 your native arch? Then,
in your example, ma_foreign:amd64 should have been installed in the
first place. See the spec[1]. In this case you could use:
Package: ma_same
Depends: ma_foreign (= ${binary:Version})
What Jakub said (MA:same packages have to be binNMUed in sync preserve
their cross-arch co-installability) relates to bug #758616 (dpkg:
support installing M-A:same packages with different binNMU version).
This means that if ma_same is binNMUed in one arch, it should be
binNMUed in all other archs too. Otherwise they can't be co-installed
currently. So you should end up with the same (binary) version on all
archs anyway.
But first, AFAIK this binNMU-in-sync isn't done always. Further, as I
understand the bug log, there's a chance for this to be fixed for
stretch. On the other side, we might end up with something completely
else which makes special binNMU handling obsolete, see "binNMU or
reproducible builds (choose only one)"-thread at debian-devel this month.
So if you assume that different binary versions might exist for the
ma_same package and
a) if ma_foreign is not built on the same archs like ma_same, or
b) if there is a valid use case with ma_same from a non-native
architecture installed, or
c) (basically the same, but currently not possible, see above) if
multiple versions of ma-same might be installed ("same" also means
co-installable, and 2 co-installed versions imply different architectures),
then you should indeed go with:
Depends:
ma_foreign (>= ${source:Version})
ma_foreign (<< ${source:Version}.1~)
About b) the spec only has a "should" prefer-native-arch, so this
"should" not be a hard reason. But I doubt that any automatic conflict
resolution would find the solution to install the non-native ma_foreign.
Greets
jre
[1] https://wiki.ubuntu.com/MultiarchSpec:
Multi-Arch: same
This package is co-installable and it must not be used to satisfy the
dependency of any package of another architecture than its own.
Often used for library packages.
Multi-Arch: foreign
The package is not co-installable and should be allowed to satisfy the
dependencies of a package of another architecture than its own.
*If a package is declared Multi-Arch: foreign, preference should be
given to a package for the native architecture if available;* if it is
not available, the package manager may automatically install any
available package, regardless of architecture, or it may choose to make
this an option controlled by user configuration.
Reply to: