Re: getaddrinfo() behaviour
Anthony Towns writes ("getaddrinfo() behaviour"):
> So here's my understanding of where we're at.
Thanks.
> First, fact finding. Everything here should be able to be agreed by
> everyone.
I'm afraid I don't agree with all of the things you claim as facts,
and I don't agree with the analytical approach you're using anyway.
But we've been over and over this and me repeating myself isn't going
to help.
So I'll skip straight to the meat. One thing you have pointed out is
that we hadn't finished discussing whether or not etch should be
fixed.
> Conversely, if we don't consider this an RC issue, changing it for etch
> doesn't seem appropriate, and at that point I don't see why we'd change
> it for sid either (at least absent an update via the IETF standards track
> process). I'd be interested to see explanations of why this should be
> considered RC.
I think that it should be changed in etch. If we change it in etch it
will make our ftp admins' lives a lot easier, if nothing else, because
they'll go back to being able to publish DNS round robin.
There are no anticipated downsides to changing it in etch except of
course the usual risk of a libc update. Ubuntu have backported the
gai.conf configuration option to their libc without difficulty,
although not in an update to an already released distribution.
I can see that the stable release managers might have another view.
We haven't really heard from them properly. My current feeling
therefore is that we should overrule the libc maintainer to
essentially propose this ourselves as an update for stable, which we
would recommend but not insist that the stable RM should accept.
Since I did the backport for Ubuntu I'm probably the right person to
prepare the update for etch (not that it's very hard).
> If so, conclusions that could potentially be drawn:
>
> (a) Using prefix matching to select IPv4 addresses isn't useful
> (b) Using prefix matching to select IPv4 addresses is harmful
> (c) Using prefix matching to select IPv4 addresses is harmful enough to
> be an RC issue for Debian
...
> If so, declaring this to be an RC issue justifies both an update to
> etch and (if necessary, which I don't expect) an NMU for sid/lenny,
> which seems all that's needed.
I don't see why RCness is relevant for updating sid.
Surely the TC should ensure that its decisions are implemented even if
we consider the issue non-RC ?
> I'm not sure if any or all of (d)-(f) would be sufficient recommendations
> to close the issue for IPv6 as well, or if there's something else that
> would make sense.
I think we should avoid getting too bogged down with IPv6. We can
safely leave that to the IETF to reconsider since we're evidently not
going to overrule the libc maintainer on that point. Hence my wording
that we think rule 6 shouldn't apply to IPv6 and we recommend the IETF
"probably" abolish it. Ie, they should think about it with the more
information and expertise available to them.
Ian.
Reply to: