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