On Sun, Oct 09, 2005 at 01:41:41PM +0200, Sylvain Beucler wrote:
[A whole bunch of stuff I severly trimmed because I like the sound
of my own voice. ^_^]
## 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
I don't know which of these is the vanilla and which is the local
rebuild, but if the ../dtach*.deb is the rebuild, then it's been
rebuilt with a newer libc6 than the old one, which has marked it as
being incompatible with versions before 2.3.2.ds1-21, while when dtach
vanilla was built, it could run with any libc6 as or more recent than
2.3.2.ds1-4.
If they're the other 'way round, then you've rebuilt dtach against an
older libc6 than it was built against in the archive. Same reasoning
applies.
In 2.3.2.ds1-21 changelog:
==
- debian/rules: Bump up shlib_dep_ver 2.3.2.ds1-21. It's required by
adding GLIBC_2.3.4 symbol.
- Bastian Blank <waldi@debian.org>:
- debian/patches/sched-update.dpatch: Update sched_[gs]et_affinity to
new interface and library version. Add GLIBC_2.3.4 versioned symbol
for new interface. (Closes: #297769)
==
ie. "Changed something in libc6. Things built against the old version
won't see the change, but things built against the new version will not
work with old versions. Tell the shlibs system of this".
So the above result is pretty much expected of any kind of rebuild, and
should really happen to anything last built before libc6 2.3.2.ds1-21
had been installed in the build-root. Or any other library that "bumped
its shlibs".
(For reference, this is the change that made Hoary users upset because
they couldn't install Sarge packages, if the Sarge package was built
against this or a later version of libc6 -- if I recall correctly.)
So I guess this is another arguement for using versions to differentiate
local packages, rather than relying on identical metadata. Because
there's _always_ going to be packages in the archive built against an
older version of something, but which still work. Have a look on your
system for packages which depend on a libc6 older than 2.3.2... I bet
you've got one or two. ^_^
> 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?
Well, it's certainly one way of doing so. Hanging around the bleeding
edge of sid and fixing bugs when they bite you is also very good
practice. ^_^
Trying to maintain a local repository of stuff you care about having
different from the Debian archive is an excellent way to see what things
get broken outside the maintainer's system and assumptions.
Trying to get those changes into the archive is very satisfying, when
you can apt-get install something and never have to worry about
rebuilding it again. You get to run the full gamut of maintainer
responses from "excellent idea, sent upstream", "thankyou very much" to
complete silence to "Dear upstream, I got this patch but don't
understand, it seems to just be changing whitespace in strings. That
can't possibly break the protocol, right?" and "Paul, you're an idiot.
BTS privileges revoked for twenty-four hours."
You're unlikely to get that last one, of course.
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
Attachment:
pgp6ZlQtWZxPo.pgp
Description: PGP signature