[buildd-tools-devel] BinNMU changelog handling for Multi-Arch: same packages

[Goswin von Brederlow]

On Thu, Jul 12, 2012 at 08:59:38AM +0200, Raphael Hertzog wrote:
> On Thu, 12 Jul 2012, Guillem Jover wrote:
> > On Wed, 2012-07-11 at 09:23:05 +0200, Raphael Hertzog wrote:
> > > 2/ we modify dpkg to allow co-installation of M-A: same packages which share the
> > >    same source version regardless of the binary version
> > 
> > As I've said before, this right here seems unacceptable. This implies
> > at least:
> > 
> >  * loosing the binNMU changelog entry, with a version in the changelog
> >    not matching the one on the dpkg db (in possibly both directions).
> >  * making installed file contents flip-flop depending on what package
> >    got installed last.
> >  * making dpkg unable to detect different generated file contents on
> >    different binary rebuilds.
> 
> There's a mis-understanding here. I was not telling to drop the check
> that ensures that the files are identical between the various arches.
> Instead I'm just saying that we must change the check that ensures that
> all package are at the same version to use the source version and not the
> binary version.
> 
> And this is required even if we move the changelog to control.tar.
> Otherwise the release team will still have to bin-nmu all arches at the
> same time, which is what they would like to avoid.

In the interim till this is solved properly, and this might be from
till wheezy up to as long as wheezy+1 if things go bad, may I suggest
the following:

* For the instability of a package from different architectures the
  source version counts. A bin-NMU version does not conflict with
  a normal version.
* Frontends put a high value on trying to match versions. If arch1
  is updated to a bin-NMU then arch2 will be updated to the same bin-NMU
  too where available.

Those two will have to happen, as Raphael says, no matter what the
changelog solution will eventually be to allow the release team to
only bin-NMU some archs for MA packages. So we might as well do that
now.

* File conflicts in /usr/share/doc/<package>/ between packages of the same
  source version are ignored. This could be even further limited to
  changelogs.

Yes, this is huge hack, a violation of layering, yada yada yada. But it
is simply the easiest quick fix. And since programs must not rely on
/usr/share/doc/<package> to be available any inconsistencies there will
be harmless.

It also preserves the changelog entries in packages so apt-listchanges
can display it and has no efect on non-multiarch systems.

MfG
	Goswin