Re: What to do about libidn?

[Florian Weimer <fweimer@redhat.com>]

On 11/09/2016 12:30 AM, Joseph Myers wrote:
> On Tue, 8 Nov 2016, Florian Weimer wrote:
>
>> This has several problems:
>
> 8. Updating libidn would be problematic for license reasons (it's
> non-FSF-assigned and upsteam is now LGPLv3).
>
>> Should we remove our internal copy and try to dlopen libidn2?  Maybe falling
>> back to libidn if libdn2 is unavailable?  Bundle libidn2?  Write our own
>> implementation?
>
> Given that glibc's libidn add-on is not itself a public ABI or API,
> dlopening an external library would seem a reasonable way of implementing
> that getaddrinfo functionality.

Would you prefer us to do that, or to drop AI_IDN support completely?

> Suppose we remove libidn (with or without keeping the libidn functionality
> through dlopen of another library).  Then we have no in-tree uses of the
> add-ons mechanism.  Do we have any use for keeping that mechanism for
> out-of-tree add-ons, or should it be removed?

We have removed the rtkaio add-on from Fedora (and downstreams will 
inherit the removal).  Fedora now has dual libcrypt builds (with and 
without NSS), but this doesn't use the add-on mechanism at all.  So we 
do not need the add-on mechanism anymore.

In the broader picture, I think we should discourage out-of-tree ports 
and functionality as much as possible because if something is not part 
of regular builds because it's not in the official source tree, we might 
only learn about fundamental incompatibilities after a release or two, 
which would be annoying.  So I'd suggest the remove the add-on mechanism 
eventually.

Thanks,
Florian