Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
On Wed, Nov 12, 2014 at 09:17:20PM +0400, Michael Tokarev wrote:
> 12.11.2014 21:05, Aurelien Jarno wrote:
> >> And there's nothing I can do about this on busybox side -- except,
> >> again, adding a versioned build-dep.
> > I'll schedule binNMUs for now, but it might be a good idea to add a
> > versioned build-dep so that it doesn't happen again.
> Please don't. I want to fix it for real today, one way or another.
Oops, that's already done, I did it just after sending the previous
> And this brings an interesting question: how to add this build-dep?
> I tried adding build-depends: libc-bin (>>2.19-12~) | libc-bin (<<2.19)
> but this one just pulls the libc-bin package not libc6 and libc6-dev.
Yes, libc-bin does not have a strict dependency on the other libc
packages, it only depends on the major version.
> Ofcourse I thouht about using libc6[-dev] in this context, but immediately
> come across the fact that on different arches, libc is named differently
> (libc6.1, libc0.3 etc).
> Should I list them all in the build-deps? If yes, what's the complete list?
It should be libc6-dev[linux-any !alpha !ia64] | libc6.1-dev [alpha ia64] | libc0.1-dev (>> 2.19-12~) [kfreebsd-any] | libc0.3 (2.19-12~) [hurd-any]
> (I tried to keep it buildable on older glibc too; but it's ofcourse possible
> to add a build-conflicts: libc6 (<<2.19-12), libc6.1 (<<2.19-12) etc --
> this is easier than listing two versions for each)
> Another thought is to add a build-time test that the thing actually work
> (eg, busybox-static ping localhost or something, or a small separate
> program to be run before real build) -- with this in mind, it might not
> be even required to add a build-dep, -- build will just fail with a
> friendly message telling to fix glibc...
Yes that might also be a good idea, and also getting that test upstream
given that the libc bug is not yet fixed upstream.
Aurelien Jarno GPG: 4096R/1DDD8C9B