Jakub Wilk wrote... > * Christoph Biedl <debian.packages.h...@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
signature.asc
Description: Digital signature