John Lapeyre <[EMAIL PROTECTED]> 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.
