On Wed 14 Oct 1998, Ian Jackson wrote: > Package: debian-policy > Severity: wishlist > > In the bug report 27823, someone reports uploading a binary-only NMU > and sends a corresponding source code change to the bug system. > > This is NOT ON, and is NOT ALLOWED according to the GPL, and ought to > be prohibited by our policy.
Firstly, as soon as an i386 maintainer uploads a newer version of some package which is _already_ ported to e.g. Alpha, the source for the Alpha version is _gone_. So, NMU uploads regardless, we're violating GPL up the yazoo already. Secondly, note that the diff included in 27823 does NOT modify the upstream source; instead, it fixes a bug in the debian/rules file. That file does does state under which license it's distributed. It's not clear in most cases under what license the files under debian/ are distributed. Do those fall under "Modifications for Debian"? Not really, as it's just a framework under which the original sources are being compiled. I may have some script which does "./configure && make"; if I distribute the resulting binary, would I be obligated to include that trivial script as well? Anyway, although the point of this bug report is valid, the bug report on which this is based is the wrong one. In most of the NMU binary-only diff bug reports I submit, only things in the debian scripts are being fixed; seldomly is a change in the upstream source necessary. Most of these NMU diffs I submit would be unnecessary anyway if the maintainers would ensure that their packages would build correctly and properly from freshly unpacked sources. Most bugs I encounter are: - build only works if the package is already installed. E.g. /var/lib/package is checked for existence, and if not, the build tries to create this. It should create under `pwd`/debian/tmp/ instead. - build only works if ./configure has been run at least once, so that ./Makefile exists. "make clean" fails otherwise. - debian/files and debian/substvars are included in the source package, with an i386 name in debian/files for example, and they're not removed during the clean target. - there's a gratuitous 'i386' in the architecture field. This happens more often than not with new maintainers who are (understandably) a bit confused about the whole process. They're also most grateful when I point out their mistake. - the package doesn't build with the current development environment. Libraries have been replaced, other utilities have changed (non- backwards compatible) behaviour. Hardly ever is an actual in the source itself necessary. > I hereby propose an amendment to the Debian Developers' Reference, > s5.5 `Interim Releases': > > Before the paragraph `When someone other than ... version number ...', > add: > > A non-maintainer upload (`NMU') MUST include the source code if any > source code changes were made. If the NMU is for a new upstream > version, the full source including upstream source archive(s) MUST be > uploaded. Recompilation uploads (for platforms other than those > whose binaries are supplied by the maintainer) which do not require > source code changes MUST NOT include the source code. See <reference > to section added below>. "the source code" needs to be more clearly defined. Perhaps a solution would be to permit more than one source package to exist in the source archive, and that the numbering for such a version is changed to include the architecture. So, in the given example, source/net/ would then currently contain: proftpd_1.1.7r3.orig.tar.gz proftpd_1.1.7r3-3.alpha.dsc proftpd_1.1.7r3-3.alpha.diff.gz proftpd_1.1.7r3-4.dsc proftpd_1.1.7r3-4.diff.gz The proftpd_1.1.7r3-3.alpha.diff.gz would contain the NMU version. If now the alpha port is done again, the -3.alpha sources are removed. Now, what should be done when the maintainer uploads -5 ? Well, IMHO there should now be the following: proftpd_1.1.7r3.orig.tar.gz proftpd_1.1.7r3-4.alpha.dsc proftpd_1.1.7r3-4.diff.gz proftpd_1.1.7r3-5.dsc proftpd_1.1.7r3-5.diff.gz Maybe even keep the -4 .dsc file updated to include the names of other architectures where there still exists that version: proftpd_1.1.7r3-4.alpha,m68k.dsc Not that pretty, but it is functional. Otherwise comtemplate symlinks. An alternative would be to separate the sources into different directories, but that makes it _much_ harder to locate the "latest" version. If I see (in the main source directory) a "package_1.2-3.m68k.diff.gz" file next to a "package_1.2-3.diff.gz" file, I'll use the former as base for my alpha port, as that will probably also fix any potential problems I come across. Aside: I've watched debian-devel and debian-private deteriorate into a playing ground for IMHO anal discussions about the most unlikely licensing nits. I fully agree that Debian should do its best to comply with such licences, however, I think one can take this too far, at which point "doing its best" isn't what's going on anymore... Paul Slootman -- home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
