Jens Reyer wrote...
> On 09/29/2015 10:13 PM, Christoph Biedl wrote:
> > 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?
Yes, and yes.
> Then,
> in your example, ma_foreign:amd64 should have been installed in the
> first place. See the spec[1].
Probably yes, but the above scenario is possible. I'm not saying it is
likely to happen, things like "Installed ma_same in the foreign arch
first, later needed the native one, too" or remainder of an cross-
architecture migration - my concern however was unvoluntary and
unnecessary breakage in the dependencies and whether I (as packager)
should provide extra precautions against this. Seems I'm not the first
one who saw that problem ...
> 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).
Relaxing the definition of "=" in a package relation, nifty.
Personally, I'm not happy about adding extra magic to version numbers
to identify binNMUs and would rather introduce a way to define a range
of version numbers a package satifies, like in
| Version: 5.25-3+b1 # upper bound
| Also-Satifies: 5.25-3 # lower bound
or by allowing two version numbers in the Version: header. But that's
certainly not my cup of tea, and might bring in a huge amount of new
problems I cannot even imagine yet.
Bottom line for me: Using "ma_foreign (= ${source:Version})" in the
given scenario is not considered a violation of packaging good
practises, so I'll still with it for the time being.
Thanks for your exhaustive explanations.
Christoph
Attachment:
signature.asc
Description: Digital signature