libidn@2 2.0.2 (new formula)

[DomT4]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

New formula for libidn@2, which is now stable upstream.

libidn@2 includes compatibility functions for other projects but I think the way to be most Homebrew-friendly is to introduce this as a new formula for now & migrate things across it as possible rather than inreplacing a bunch of projects to use the correct header:

This library is backwards (API) compatible with the libidn library. Replacing the idna.h header with idn2.h into a program is sufficient to switch the application from IDNA2003 to IDNA2008 as supported by this library.

[DomT4]

Ah, the classic osc testing failure 😒.

[ilovezfs]

I'm 👎 on using versioned formulae for new versions.

[ilovezfs]

This should be recast as an ordinary version upgrade for the main libidn formula, or deferred until that becomes feasible.

[DomT4]

I'm 👎 on using versioned formulae for new versions.

How do you feel about flipping it and this becoming libidn & adding a libidn@1 formula then? That would seem more in line with how Homebrew has handled breaking updates so far.

[ilovezfs]

I'd prefer to avoid libidn@1 if possible. Have you tried just upgrading it?

[DomT4]

No, but the entire header structure changed, as well as the library versioning, so best case scenario everything needs a revision, worst case scenario almost everything needs inreplace-ing to use the right unified header & reported upstream.

I mean, I can do it that way, because slowly as we're discovering libidn2 is becoming expected upstream, but this way felt more Homebrewish so I started here.

[MikeMcQuaid]

Agreed about trying an update and falling back to a libidn@1 formula if that's not possible and falling back again to a libidn@2 formula if the vast majority of formulae are on libidn@1 vs. 2.

[ilovezfs]

"This library is backwards (API) compatible with the libidn library.
Replacing the idna.h header with idn2.h into a program is
sufficient to switch the application from IDNA2003 to IDNA2008 as supported
by this library."

[DomT4]

Of the mandatory stuff:

• freediameter - Fixed with some inreplace-ing, reported upstream.
• getdns - Needs stringprep, which seems to have been dropped???
• git-annex - Builds without any issue, but unsure it's actually using libidn. Removing it locally doesn't obviously break anything.
• hesiod - Add support for libidn2 achernya/hesiod#13
• knot
• lftp
• libswiften
• loudmouth
• mcabber
• monotone
• pidgin
• skipfish

Will keep testing. Anything without an explanation hasn't been checked yet.

[ilovezfs]

getdns - Needs stringprep, which seems to have been dropped???

mind asking libidn2 upstream what the deal is there?

[ilovezfs]

git-annex - Builds without any issue, but unsure it's actually using libidn. Removing it locally doesn't obviously break anything.

Possible it's not finding it. @joeyh is there something we need to do to get git-annex to use libidn/libidn2?

[joeyh]

ilovezfs wrote:

git-annex - Builds without any issue, but unsure it's actually using libidn. Removing it locally doesn't obviously break anything. Possible it's not finding it. @joeyh is there something we need to do to get git-annex to use libidn/libidn2?

That was needed for the xmpp support, which was removed from git-annex recently. You also no longer need gnutls installed to build git-annex.

…

-- see shy jo

[ilovezfs]

@joeyh Thanks for the help!

[DomT4]

mind asking libidn2 upstream what the deal is there?

https://gitlab.com/libidn/libidn2/issues/28

[ilovezfs]

@DomT4 looks like upstream responded

[DomT4]

Aye, I saw.

The reply was impressively detailed & I'll leave a thanks for that shortly, but somewhat threw me in terms of realising some of the I guess not non-standard but nonetheless less simple libidn usage from the 1.x branch is a fair bit more work than swapping out headers & library linkage.

Not planning to give it up but it certainly gave me an appreciation this may be more involved than the upstream README initially made me think 😄.

[ilovezfs]

@DomT4 What's more, it seems your inquiry triggered some upstream commits. Neat!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[DomT4]

@probot-stale[bot] Complicated but not yet dead.

[ilovezfs]

I love how you talk to the 🤖

[DomT4]

It's the easiest way to get it to drop the stale label without simply rebasing, force pushing & having the test-bot do a pointless run 😅

[ilovezfs]

Now it will leave you alone.

[DomT4]

Cool, thanks 🙇.

This is something I'm still paying attention to, but with upstream adding more advice on how to transition to libidn2, other upstreams seemingly completely ignoring patches I've sent so far & not wanting to spend all the time I have for FOSS on this things have slowed a fair bit.

[ilovezfs]

Maybe vendor it into the two (curl and wget) that can't use version 1 and call it a day?

[ilovezfs]

If you prefer to close both PRs, I'm also fine with that if you want to move on from this.

[DomT4]

Maybe vendor it into the two (curl and wget) that can't use version 1 and call it a day?

Yeah, maybe that's not a bad way to go for now to be fair. I guess we could always come back to this in 3/4/5/6 months, or as more upstreams migrate & make vendoring unpleasantly heavy to maintain for folks.

[ilovezfs]

Do you think a significant number of users would actually want to brew install libidn@2 for their own purposes?

[DomT4]

At this point I wouldn't say it has the same testing appeal in a Homebrew context as openssl@1.1 did & does. It could be useful to some I'm sure, but building libidn2 from source is a pretty quick & simple process compared to OpenSSL.

[ilovezfs]

Vendoring seems fine to me then, but we can always revisit libidn@2 later if there are users asking for it.

[DomT4]

#13899