[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
email.

> 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
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: