[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Binary-only uploads cause dangling 'Source:' reference in .deb's (Was: Re: Why Katie thinks it's an NMU?)

(moved to d-d)

On Fri, Apr 02, 2004 at 12:28:32PM +0100, Colin Watson wrote:
> On Fri, Apr 02, 2004 at 11:53:43AM +0200, Jeroen van Wolffelaar wrote:
> > Any .deb indicates its source, including binary-only NMU's,
> I'm afraid you're wrong there; I have some binNMUed packages here and
> they do *not* indicate the source version.
>   $ dpkg -I liboo2c_1.5.9-3.0.1_powerpc.deb | grep Source
>    Source: oo2c
> I know of no non-heuristic way to find the exact source version
> associated with a binary-only NMU.

That is because the source _was_ changed for this binary only NMU:

(from the changelog:)

oo2c (1.5.9-3.0.1) unstable; urgency=low

  * Binary-only NMU for powerpc.
  * Really build for libgc1, not libgc6c102.

 -- Colin Watson <cjwatson@debian.org>  Thu,  6 Nov 2003 12:18:19 +0000

And, the version at the first line of the changelog, is the source
version. So, the dpkg-genchanges and dpkg-buildpackage scripts take that
version as source version, and by uploading the thus produced binary
without this changed (!) source, you get a binary without corresponding

Because of the heuristics in katie (indeed, I missed that, I looked at
various check_source functions and such), this upload was still
accepted, don't know why [I don't know the _reason_, I do know why it's
accepted technically] (the change in katie was committed end july 2003
by ajt, with comment: kelly, lisa, jennifer: update to use the new

IMHO, this is a suboptimal solution. In theory, with source header you
can always track the source. However, because currently binary-only
NMU's which don't follow this property are accepted by katie, this isn't
always true.

I see two possibilities to fix this, as this is a useful property to
have (and gets rid of heuristics):

- A binary upload is to be performed indeed binary-only, that is, no
  changes to the source beforehand (thus, also no change to the
  changelog). To build a binary NMU this way, one needs to override the
  .deb version at dpkg-gencontrol time. Can be done by a hack in
  'rules' (hack, because this _is_ a source change...), or making some
  kind of interface to that, so that dpkg-gencontrol sets version of
  1.2-1.0.1 if for example environment orders it to do so (enviroment
  var is set by dpkg-buildpackage in respond to some command-line
  Problem: rebuild isn't documented in changelog
  Problem: dpkg-gencontrol isn't mandatory. Other solution: a tool to
  change the version of a .deb after it's created, by modifying the
  Version: and Source: fields correctly.

- The changelog IS updated, but the source version is still taken as the
  original one. Unless you want to hand-edit the .deb's,
  dpkg-buildpackage will then need to be changed such that correctly
  understands this (i.e., you need to override what the source version
  is, it cannot be taken from changelog), and thus makes a correct
  Source: header in the .deb's.
  Binary NMU's are then not strictly binary-only (you cannot rebuild it
  from source, you'll then lose the updated changelog). However, this is
  current practice, and I think the changelog is a good candidate to be
  the only exception to the 'binary-only' rule, for obvious reasons.

I'm a bit indifferent about whether or not changelog updates for binary
NMU's are okay, because of its nature, there is no source-change, and
one could argue a changelog entry is unneeded, while OTOH, the binary
.deb obviously _did_ change.

> > so no version number fiddling is needed to find the source (which
> > would be impossible too, is 1.2-0.0.1 a binary NMU of 1.2, or of
> > 1.2-0? Though nonstandard, the latter isn't forbidden)
> katie tries both of those possibilities.

Which is IMHO a bit of a hack (because: heuristics), and also one cannot
rely on the Source: header then: I consider this a bit strange, Debian
mandates sources for every binary package, but at the same time,
binary-only uploads are accepted with a dangling reference to the source


Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)

Reply to: