On May 16, 2010, at 18:42, Mats Erik Andersson wrote: > in the bug reports #580473 and #581552, for atftp and vtun, > respectively, I have tried to bring attention to the fact > that a new resolve ordering between IPv4 and IPv6 is in effect > from Debian testing and onwards.
This isn't an ordering issue; standard gethostbyname() simply doesn't return IPv6 addresses. Are they turning on "options inet6" in resolv.conf (or hard-coding the equivalent in libc)? From what I read in the man page for resolv.conf, it sounds like that returns only IPv6-format addresses (mapping IPv4 addresses to IPv6 in the process), instead of the standard IPv4 addresses, which I think would break every gethostbyname() application that doesn't know about this extension and explicitly check for it. (Really, I can't figure out what "options inet6" is good for. If you're going to hack your application to know about these extensions, you might as well just use getaddrinfo. Even if you do hack some of your applications to expect IPv6 addresses from gethostbyname, the config file option affects *every* such application.) If it's intentional, it might have been better to simply remove gethostbyname altogether and force packages to break in more obvious ways instead of occasionally subtle ones (e.g., failing to process addresses correctly in infrequently-used paths). Or, a more gentle approach: First, mark gethostbyname deprecated, so the compiler and/or linker warn every time it's seen. And, if it's intentional, where was it discussed before the decision was made? Is there a more appropriate list for that discussion than this one?? That makes me wonder if it's just a mistake, that should be corrected soon.... Ken -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
