Opened 5 years ago

Closed 5 years ago

#57886 closed enhancement (wontfix)

libiconv doesn't support "UTF8" alias

Reported by: kyz (Stuart Caie) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: chrstphrchvz (Christopher Chavez)
Port: libiconv

Description

I'd like libiconv to support the "UTF8" alias for the UTF-8 charset in iconv_open()

Background: with libiconv 1.13, the maintainers decided to limit various aliases to specific OSes (see 2008-04-06 changelog entries), and they decided "UTF8" was an HPUX specific alias (I would disagree), so libiconv >= 1.13 doesn't recognise "UTF8" as an alias except when compiled on HPUX.

My software, cabextract, used "UTF8" because it was the most portable name for the UTF-8 charset amongst iconv() implementations. For example, newlib does not support libiconv's preferred "UTF-8", only "UTF8" or "UTF_8", so "UTF8" is the common denominator.

"UTF8" works on all common platforms... but not Macports. "UTF-8" works on all common platforms, but not systems using newlib.

I've had to change my software just for Macports, now it tries out multiple names for the same charset until one works. This is not normal. It would be better if Macports changed to support "UTF8" as an alias.

Please add a patch to libiconv that uncomments line 61 of lib/encodings.def

Change History (8)

comment:1 Changed 5 years ago by mf2k (Frank Schima)

Cc: ryandesign removed
Owner: set to ryandesign
Status: newassigned

comment:2 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

I remember us talking about this in email before, so thanks for following up on it.

As you point out, it's the developers of libiconv who chose to do this, so it's not a MacPorts-specific problem. The problem would affect anyone who uses libiconv on macOS, whether they get it from MacPorts, Homebrew, Fink, or compile it themselves. I don't feel that each package management system should have to forever maintain a patch for this; I feel that the upstream libiconv source code is the correct place to make the change. Have you already discussed it with the developers of libiconv? If not, that's what I'd suggest.

comment:3 Changed 5 years ago by kyz (Stuart Caie)

I have written to the developers of libiconv (today, at the same time as this request), but I haven't heard back from them yet. I'll let you know what they say.

Even if they agree, it may be quite some time before the change becomes officially available. libiconv 1.15 was released about 6 years after 1.14; what if libiconv 1.16 is released in 2024? In such circumstances, would it be OK to maintain a patch until the next libiconv release?

comment:4 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Of course, and I'll probably make the change regardless of whether they do, I just prefer whenever possible to push changes back to the upstream developers so that as many users as possible can benefit and so that I don't have to maintain lots of patches.

comment:5 in reply to:  3 ; Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to kyz:

I have written to the developers of libiconv

Have they responded?

comment:6 in reply to:  5 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

Replying to ryandesign:

Replying to kyz:

I have written to the developers of libiconv

Have they responded?

Yes, and the request was for the UTF8 alias was rejected: https://lists.gnu.org/archive/html/bug-gnu-libiconv/2019-01/threads.html#00000.

comment:7 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

Cc: chrstphrchvz added

comment:8 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: wontfix
Status: assignedclosed

Thanks for the link. The developer has explained in his mailing list response why he doesn't want to add the alias. I'm sure he understands this stuff better than I do, and I don't want to second-guess him, so I won't make the change in MacPorts libiconv.

Note: See TracTickets for help on using tickets.