| Sylvain Beucler 2005-10-09, 7:48 am |
| Sorry for the delay..
For the record:
>
>
>
>
>
>
>
>
>
>
>
>
> Apt is acting exactly like you'd expect. You've managed to rebuild
> mutt and dpatch and get the same metadata. This is probably the reason
> binary NMUs have to increment the version by .0.1, as otherwise they
> won't actually be automatically selected... And the whole "can't upload
> versions that already exist." I guess.
>
> I guess my question is, did you actually change dpatch and mutt, or just
> rebuild? It might be enlightening to debdiff the Debian and local .deb
> files for these two and see if they differ in a way that apt doesn't
> actually care about. (Which might be a bug... Or might be a feature)
# apt-src install & build - identical
$ debdiff mutt_1.5.9-2_i386.deb ../mutt*.deb
File lists identical (after any substitutions)
No differences were encountered in the control files
$ debdiff dpatch_2.0.10_all.deb ../dpatch*.deb
File lists identical (after any substitutions)
No differences were encountered in the control files
# apt-src install & build - NOT indentical
# Note: the build system has vanilla libc6, not the patched one
$ debdiff ../dtach*.deb dtach_0.7-1_i386.deb
File lists identical (after any substitutions)
The following lines in the control files differ (wdiff output format):
----------------------------------------------------------------------
Depends: libc6 (>= [-2.3.2.ds1-21)-] {+2.3.2.ds1-4)+}
^^^ that's the problem, apparently
The control file says:
===
Package: dtach
Architecture: any
Depends: ${shlibs:Depends}
===
# The patched libc6
$ debdiff libc6_2.3.2.ds1-22_i386.deb ../libc6_2.3.2.ds1-22.1_i386.deb
File lists identical (after any substitutions)
The following lines in the control files differ (wdiff output format):
----------------------------------------------------------------------
Version: [-2.3.2.ds1-22-] {+2.3.2.ds1-22.1+}
Provides: [-glibc-2.3.2.ds1-22-] {+glibc-2.3.2.ds1-22.1+}
Installed-Size: [-15548-] {+15520+}
>
>
>
>
>
>
>
>
> Erk. ^_^
>
> Admittedly, it's prolly worth casting an eye over the shlibdeps-building
> stuff. You occasionally see bad NMUs when the NMUer forgot to check that
> the version-munging code to build a not-too-restrictive shlib deps
> version isn't prepared to parse NMU version numbers.
>
> Happily, you more often see changelogs for packages which are _fixing_
> that type of issue. (eg. search for NMU in libc6's changelog.Debian. ^_^)
Unfortunately I'm not very familiar with NMUs and shlibdeps-building
:/ I guess I need to actually maintain a Debian package to understand
all those issues?
--
Sylvain
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|