[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

binNMUs?



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 (pkern@debian.org) [110801 13:25]:
> On Fri, Jul 29, 2011 at 06:29:20PM +0200, Andreas Barth wrote:
> > * Andreas Barth (aba@not.so.argh.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
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


Reply to: