Bug#27906: PROPOSED] Binary-only NMU's
Paul Slootman writes ("Bug#27906: PROPOSED] Binary-only NMU's"):
...
> 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.
This needs to be fixed, then. Unless we can guarantee that the same
version of the same package will always work on all architectures, we
need to be able to have differing source versions simultaneously while
portability issues are sorted out.
I've CC'd this to Guy for his comments.
> 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?
GPL v2, s3, 4th para, emph mine:
... For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, _plus the scripts used to
control compilation and installation of the executable_.
That would be the debian/rules file. (This means that the rules file
for a GPL'd work must have a GPL-compatible licence, which is not a
problem.)
> 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.
This is irrelevant.
> 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:
This is very interesting - thanks for sharing it with us. Perhaps
some of the autorecompilation on i386 could be beefed up to make the
compilation work at least there. However, I don't think this is
relevant here.
...
> Hardly ever is an actual in the source itself necessary.
`Source code means ...'
> > 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.
I think it's perfectly clear. The source code for a Debian binary
package is the corresponding Debian source package.
> 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:
...
Indeed.
...
> 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...
If I find that I can't compile a version of dpkg on another
architecture because someone hasn't included the source in their
upload then I'll send a stroppy email insisting that they comply with
my licence terms.
Roman Hodek writes ("Bug#27906: PROPOSED] Binary-only NMU's"):
> [Ian:]
> > GPL v2, s3, last para, emph mine:
> > If distribution of executable or object code is made by offering
> > access to copy from a designated place, then offering equivalent
> > access to copy the source code _from the same place_ counts as
> > distribution of the source code, even though third parties are not
> > compelled to copy the source along with the object code.
> >
> > The BTS is not the same place as the FTP site. For example, many
> > people make CDs and mirrors of the FTP site but not of the BTS.
>
> That is right, but the GPL doesn't say here that this is the only
> valid method of supplying the source code.
It is, however, the way _we_ distribute the source code. We are
required to distribute the source code somehow, and if you think that
paragraph doesn't apply, then I'd like you to point out where we're
distributing it at all.
...
> - dpkg-buildpackage first cleans the build tree, then builds the
> source, and finally rebuilds the binary packages. If you have a
> slow machine like me and waited, for example, 12 hours until the
> error happened, you don't want to throw all the results away that
> easily...
>
> Ok, I could build the src pkg after the bin pkg by calling
> debian/rules clean and dpkg-source --build manually, but that's
> again manual work, which is time consuming. And time counts if you
> do that not only once, but in masses.
I'm sorry to say `tough' here, but the only way to reliably produce
source and binary packages that correspond to each other and that work
is to build from a clean source tree.
> - If a new src version appears in the archive, all other archs have
> to recompile this src pkg again (even i386, strictly speaking). If
> there are no changes in their binary pkgs, this is a lot of wasted
> CPU cycles... And our automatic tools for detecting new source
> version (quinn-diff) cannot detect the case of "this won't change
> anything for you, you don't need to rebuild it."
Recompiling on other architectures ensures that the `per-architecture
patch' which is supposed to fix compilation on one architecture
doesn't break others.
...
Hartmut Koptein writes ("Bug#27906: PROPOSED] Binary-only NMU's"):
> [Ian:]
> > I don't understand your objection. All I want you to do is not to
> > give dpkg-buildpackage the -b flag if you've modified the source, so
> > that you upload the source along with your binaries. This is exactly
> > what you're doing atm, except that you're not distributing the source.
>
> Hmmm , this means we porters should upload also the source without asking
> the maintainer first?
If you feel it appropriate, yes. If this is currently not policy then
perhaps we should make it so.
Ian.
Reply to: