> 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
