On Fri, Apr 02, 2004 at 04:35:13PM +0100, Colin Watson wrote: > On Fri, Apr 02, 2004 at 04:29:54PM +0200, Jeroen van Wolffelaar wrote: > > 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. > > I don't know if you realize this, but *all* binary-only NMUs currently > are performed this way. This is nothing remotely new, and I didn't do > anything non-standard. The point is that new source isn't uploaded, and > the changelog entry is considered sufficiently minor not to worry about.
I do realize that, sorry if I wasn't clear. I didn't want & didn't mean to say this particular oo2c case was wrong, I was rather trying to get clear (also for myself) why this was failing. Anthony Towns already pointed out in this thread the (very old...) bug[1] in the BTS against dpkg to fix this issue, filed by himself about 4 years ago. I failed to find that bug when googling for it. About everything I said in my mail was already said by Anthony Towns in his bugreport. Including the two possible approaches to solve it (change changelog and make that work alright, or don't change changelog, and have a real just-recompile, even the method (env vars) is in it...). What I didn't say, and Antony Towns did, is "So, could something to this effect be applied to dpkg soonish, please?" (to no effect to-the-moment). Pro the non-changelog thing is, that one can order a buildd to recompile with correct version number, while currently manual changelog editing is needed. > You really do have to update the changelog, IMHO; if nothing else > something somewhere needs to say why you're making the binNMU. In the .changes, dpkg-buildpackage --rebuild=n would force you to also supply a text for 'Changes:'? I don't really think it needs to be in the changelog, as it was merely a fix for a botched build. Anyway, IMHO whichever way is chosen doesn't matter much, I think the most important thing is that either is implemented. There are currently less than 94 binary NMU's in the archive across all archs. It deals with about 10 source packages I think, plus quite some on s390 (which has by far the most binary NMU's). I think it's achievable, if this dpkg bug is fixed, to have sarge without dangling Source: references. --Jeroen [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=62529 PS: kernel-patch-2.4.x-mips (which is Arch: all?) has versions like 2.4.22-0.030928.5, which seems a bit wierd to me. How is one supposed to NMU or bin-NMU _that_? -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
