Re: Bug#27906: PROPOSED] Binary-only NMU's
On Mon, 19 Oct 1998, Ian Jackson wrote: ianJohn Lapeyre writes (Re: Bug#27906: PROPOSED] Binary-only NMU's): ian I just want to register my vote for allowing this. ian ianWe are not voting. This was an example of colloquial discourse. ian It is an unstable distribution-- this is meant to be a temporary ian situation; putting the patch on the BTS I think easily qualifies as making ian the source available. ian ianI disagree. The wording of the GPL disagrees with you. The Debian ianSocial Contract is unclear. OK, the GPL requires that the source be made available at the 'same place'. Suppose, however, that I write a program and compile it under solaris and my cc is a link to gcc, and 'cc' is hardcoded in the makefile. Then I put a binary and a source distribution on a site. Someone gets the source, tries to compile it under solaris and it fails, because it needs gcc, and 'cc' is the sun compiler on his machine. Am I violating the GPL ? (or imagine some library is hardcoded to be in /usr/opt, and the other guy keeps it in /usr/local) If an Alpha porter changes a rules file to exchange 'egcc' for 'cc', builds a binary, but does not upload a new source, is the GPL being violated ? This is in fact what the bulk of the changes to my packages consist of. I can imagine cases in which significant changes to the source are made. In this case, one could argue that a source file should be made available, in order to avoid establishing a precedent that could later be exploited by some unscrupulous person. btw, the above argument may sound silly, but some pieces of software are more difficult to compile than others. How much expertise must one assume the recipient has in order to distribute under the GPL ? The law probably makes allowance for intent to deal with gray areas. An example at the other extreme is Karma, by Richard Gooch. He distributes linux-binaries and source under the GPL. I tried pretty hard to compile the thing, but failed. On the other hand I have succesfully compiled dozens of other GPL'd packages. I Gooch violating the GPL ? John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Bug#27906: PROPOSED] Binary-only NMU's
Perhaps we should relax this policy, then. I tend to agree. The wait seems to be the crux of the problem. Perhaps we could let porters make NMU's with no wait at all? This would be helpful in some cases, but doesn't solve the problem that other archs have to recompile that NMU version, too, even if they're not affected by the change. Roman
Re: Bug#27906: PROPOSED] Binary-only NMU's
On Sat, Oct 17, 1998 at 08:55:22PM -0700, John Lapeyre wrote: 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. I also have received patches this way from Paul and have no objection to this method. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Bug#27906: [PROPOSED] Binary-only NMU's
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
