Hi, this comes from a private conversation which actually shouldn't be private (redistributing with permission from Phil). So following up in public now.
* Philipp Kern ([email protected]) [110801 13:25]: > On Fri, Jul 29, 2011 at 06:29:20PM +0200, Andreas Barth wrote: > > * Andreas Barth ([email protected]) [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 ability. > 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? Andi -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
