Bug#27906: PROPOSED] Binary-only NMU's
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: paul@wurtel.demon.nl | work: paul@murphy.nl | debian: paul@debian.org
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
Reply to: