On Thu, Sep 02, 2010 at 02:42:35PM +0200, David Kalnischkies wrote: > Hello (again) Simon Richter, > 2010/9/1 Simon Richter <sjr@debian.org>: > > when trying to install a multiarch package that has been binNMUed on one > > architecture, apt complains about being unable to resolve the implicit > > conflicts, as the version number is not the same across all > > architectures. > This is really a problem… > but not only here but in general as at least changelog.Debian.gz will differ > (a bit) and can therefore not be shared between the installed packages. > So, i guess it is a bug in the MultiarchSpec [0]. (cc'ing Steve Langasek) > source:Version is a problem as the source version is not always the same > version as the one the binary rebuild is based on - e.g. comerr-dev > (bad example, but the first i found) which would have in a binary rebuild > e.g. version 2.1-1.41.12-2+b1 while source is e2fsprogs (1.41.12-2)… Sorry, it's not a bug in the spec, but an acknowledged limitation. Multi-Arch: same packages *must* be kept in version lockstep across architectures, which means that binNMUs will be of reduced value for such packages. Neither multiarch support nor binNMU support is a hard requirement for packages in the archive. We will probably have to set some rules in policy about what the expected behavior is going forward, and we may want to tune the binNMU implementation in wanna-build to be more friendly to multiarch (or at least to fail gracefully); but ultimately there will be some use cases that just don't work anymore via binNMU, and it may be more straightforward to use sourceful NMUs for these packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature