Re: glibc, bug 438179 et avenir de/dans etch
On Wed, Sep 26, 2007, Pierre Habouzit wrote:
> Steve a voté blanc FWIW. Aba et iwj ont voté pour changer.
C'est un peu jouer sur les mots : il vote "Do not use rule 9"
au-dessus de "Sort IPv4 addrs" et je pense que "Further discussion" est
plus précis que "blanc". Dans <20070909113955.GI833@dario.dodds.net> il
est d'accord sur tous les points avec iwj et recommande à Kurt de
parler à l'IETF pour changer cette règle. Il écrit que ne pas suivre la
règle de la RFC est une meilleure solution que la suivre dans
<20070924004802.GD7652@dario.dodds.net>.
> Ce qui serait nettement mieux, et qqn l'a suggéré, serait d'avoir un
> gethostbyname2 qui prendrait des flags qui impacteraient la méthode de
> tri, et faire normer ça dans POSIX. Si la glibc a ça, ça entrera dans
> plusieurs autres libs, et les applis qui ont vraiment besoin de RR
> pourront demander _explicitement_ d'avoir du RR, et non parier sur le
> fait que gesthostbyname en fait. Je rappelle que le comportement RR de
> gethostbyname n'est pas contractuel, y'a rien qui dit nulle part que ça
> marche comme ça. Je sais que c'est un argument qui est un peu foireux,
> mais au lieu de jaser sur le fait que le comportement change, ptet qu'il
> faudrait songer à inventer la fonction qui norme ce comportement once
> and for all non ?
C'est une option tout à fait raisonnable, mais ça ne justifie pas
plus de changer le comportement de getaddrinfo() : pourquoi ne pas
changer de comportement avec la nouvelle interface, à partir du moment
ou la possibilité d'un classement est évoqué dans l'API ?
Personnellement je trouve assez naturel que la libc renvoie les IP
dans l'ordre des informations DNS obtenues par défaut et soit
configurable (par l'admin ou par API) pour les classer, pas que la libc
décide de les classer lorsqu'on met à jour son système.
--
Loïc Minier
Reply to: