Re: Binary-only uploads cause dangling 'Source:' reference in .deb's (Was: Re: Why Katie thinks it's an NMU?)
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 <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
> > 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
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: