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?
Christoph
Attachment:
signature.asc
Description: Digital signature