this comes from a private conversation which actually shouldn't be
private (redistributing with permission from Phil). So following up in
* Philipp Kern (email@example.com) [110801 13:25]:
> On Fri, Jul 29, 2011 at 06:29:20PM +0200, Andreas Barth wrote:
> > * Andreas Barth (firstname.lastname@example.org) [110729 13:27]:
> > > Otherwise, I think having binNMUs for only one arch is quite often
> > > sensible - but we might want to switch +buildX-source-uploads for
> > > scheduling the whole archive.
> > What is the technically reason for "we cannot do binNMUs anymore"?
> > We might just loose the changelog information - or put the additional
> > reasons in files like /usr/share/doc/$pkg/binary-upload-$arch-$number.
> > Of course, for just re-uploading all architectures the +buildN would
> > be good. But for special cases binNMUs are still useful for me.
> +buildN makes only sense if we agree by policy that we're allowed to
> make such uploads, though.
Sure, but I think we should (question is just how to do that - mostly
needs support on the dak side).
Also, I think we still have a reason for +b(something) as sometimes we
just need to rebuild on a single architecture (because something
strange has happend there), and I don't want to get rid of that
> The technical reason is that it's not guaranteed that a package yields
> the same files in the non-multiarch directories. But I guess those
> are actually RC bugs that need to be filed against all packages
> converted to multiarch and not adhering to this.
Yes - this means we should have an automated checker for that.
> (This includes files
> like those created by dh-buildinfo, which only needs to be present in
> a chroot to be picked up by cdbs; it might include other files, like
> compressing stuff on your own with gzip, not passing -n.)
One way would of course be to get rid of changing the changelog (and
instead add an extra file to
/usr/share/doc/$package/binNMU-$arch-$num-$reason or so). Via that, we
wouldn't have conflicting files. Does that sound very insane?