Bug#27906: PROPOSED] Binary-only NMU's
John Lapeyre <lapeyre@physics.Arizona.EDU> writes:
> Sorry, I missed most of this. I get a lot of binary only NMU's
> from Paul and Roman with an accompanying diff that also goes in the BTS.
> I just want to register my vote for allowing this.
> It is an unstable distribution-- this is meant to be a temporary
> situation; putting the patch on the BTS I think easily qualifies as making
> the source available. Consider also, that even without the diff, a
> package is far easier to build than a typical DFSG compliant piece of
> software that I download from sunsite. DFSG does not say, 'must build
> with a single command on every platform' . Finally, it makes life much
> easier for both of the developers involved.
> John
Though I haven't yet gotten any such bugs, I'd welcome them being sent
this way. It's certainly much better than doing a NMU with source
that then wipes out the source to the i386 binary sitting there. This
way, whether or not one is complying with the GPL depends on one's
definition of "in the same place" - some might argue that the place
debian packages are distributed is "servers named *.debian.org using
standard public-access internet protocols" (that is, debian.org
servers using passwordless http or anonymous ftp). While this is
stretching some definitions a bit, within those stretched definitions
this patches-in-BTS system complies with the GPL.
On the other hand, what Ian seemed to be suggesting, of requiring
porters to do - binary+source NMUs - would break the GPL, since the
new source would wipe out the source for the i386 binary already
present. I prefer an interim solution that is at least compliant with
stretched definitions, rather than one that blatantly breaks the GPL.
So in short, we should look at what to do - the nmu-specific .diff
files proposal seems promising; it needs to be fleshed out a bit more,
though. In the meantime I suggest that we stick with the
patches-in-the-BTS system, so long as such patch-bugs are marked with
a priority high enough to keep the package out of the official
release. (what level does that?) The rationale for this is that we
want CD vendors who distribute only binary CDs to be able to take a
snapshot of the source directories and thereby have the source the GPL
requires them to have around for three years after the fact. Also,
it's in general a sad event when a source CD can't be used to build
everything on the binary CD.
To appease those who are still queasy about this interim solution, we
could add a directory to the source portion of the archive
specifically to contain these BTS patches before the regular
maintainer integrates them into the next package. It's ugly, but this
is only an interim ugliness (I hope).
Hmmm - it occurs to me that some kind volunteer could be designated
"NMU patch holder" - porters would CC them on the BTS-patch messages
and then they would keep that area (the BTS patches area) of the ftp
archive up to date. This might actually be workable.
Reply to: