Re: Bug#27906: [PROPOSED] Binary-only NMU's

[Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>]

> This is NOT ON, and is NOT ALLOWED according to the GPL, and ought
> to be prohibited by our policy.

It's the consent of many porters (including James Troup, ..., me, ...)
that we don't break the GPL by bin-only NMUs, as the complete source
is still available in an "official" way: first the usual source
package, plus additionally a patch available from the BTS.

I'm aware that this is not 100% clean, but bin-only NMUs are an
important instrument for us porters. There are some circumstances
where they seem necessary and/or justified:

 - An existing package is hosed (because something went wrong during
   the build process, but this isn't noticed before the upload), and a
   recompile is needed to get the pkg working.

   This usually doesn't need a source change, so is still possible
   after Ian's proposed policy change. But I could imagine cases where
   little changes are necessary to build the package, for example if
   the build environment has changed in the meantime. And the build
   environment can depend on the architecture...

 - You need some package quickly, either because it's important to the
   system, or some other packages source-depend on it and need be
   built, or release date is a few days, or ... (Of course all
   assuming that the package doesn't build out-of-the-box from the
   source package.)

I've now recompiled hundreds, if not thousands, of packages for m68k,
so I hope I can speak with some experience: If you go the normal way
(report a bug, wait some time, then make a bin+src NMU), it takes ages
until you have a fixed version in the archive. Either maintainers
don't act on the bug report, or you forget 1 of your 50 currently
outstanding reports, and so on.

I admit that bin-only NMU are done sometimes where normal (bin+src)
NMUs should have been used instead. I think bin-only NMU should be
done only if the changes do not affect building on other archs (i.e.,
if those need the patch, too) and would not change the contents of
binary packages on other archs. But if those two conditions are
satisfied, I think a bin-only NMU is ok. Additionally, if it's urgent
to get the package out of the door, IMHO a bin-only NMU is also
justified, if it seems likely that the maintainer releases a new
version including the patch soon.

> Section 4.3 `Architectures' needs a complete rewrite, including
> details of binary-only porter NMUs. That'll want some discussion.

Yep, the current text seems a bit ancient :-) But does the bin-only
NMU topic belong here?

Roman