(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 <[EMAIL PROTECTED]> 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 source. 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 source_exists). 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 option). 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 package. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl