gettext @0.21.1: newer version available

[tifrueh (Timo Früh)]

A new version (0.22.3) of gettext is now available.

The old version still builds without problems on Sonoma, but it might cause problems for other ports that depend on it.

An example for this seems to be aria2. Upgrading gettext solved ​aria2 issue #208.

Might this also have something to to with the build problems of the port neovim? (#68126)

[ryandesign (Ryan Carsten Schmidt)]

Oh right, ​that problem. I have not begun working on this gettext update but I agree it needs to happen. If somebody else wants to submit a PR to update it that's fine, bearing in mind that all of the subports have to be tested.

[tifrueh (Timo Früh)]

I've been trying to write an updated Portfile, but the subport gettext-tools-libs fails with this message:

:info:build libtool:   error: cannot find the library '../../gettext-runtime/intl/libintl.la' or unhandled argument '../../gettext-runtime/intl/libintl.la'

It seems to me that the new gettext tries to use the included libintl instead of the previously installed version from gettext-runtime, no matter what I do.

I've tried the following configure args, to no avail:

--with-installed-libintl
--with-libintl-prefix=${prefix}

So I tried to find a bug in configure.ac/Makefile.am, but wasn't able to find anything, probably due to my having no experience with autotools.

Does anyone more knowledgeable than me have a better idea what's going on here?

---

Additionally, I wanted to ask if there is any particular reason why the gettext package is split into subports like this. Would it not be simpler to build and install the whole package in one go, like the Arch Linux or homebrew gettext package? That might solve the abovementioned problem.

Arch Linux ​https://gitlab.archlinux.org/archlinux/packaging/packages/gettext/-/blob/main/PKGBUILD?ref_type=heads

homebrew ​https://github.com/Homebrew/homebrew-core/blob/a91c41aec30b8454041fdc91d1f028db11927b09/Formula/g/gettext.rb

---

Note: Looking at the Arch Linux package I saw that libtextstyle is being disabled there, due to it depending on libcroco which is supposedly unmaintained and insecure. Might it be a good idea to do the same thing on MacPorts?

[ryandesign (Ryan Carsten Schmidt)]

The libintl.la problem you mentioned is also cited in #68030, of which this ticket is a duplicate. I am not surprised updating to 0.22 is more complicated than just updating the version and checksums. That's why I've procrastinated doing this update.

A considerable amount of time and effort was expended a couple years ago to separate the former monolithic gettext port into the subports you see today. See #58526 and ​PR 7399. The split was performed both because it is how the developers of gettext recommend it be packaged, and because the different parts of gettext have different licenses so we need them in separate ports so that the MacPorts license checking machinery can make correct decisions. Previously, we were lying about the license of the gettext port because specifying it correctly would have caused MacPorts to determine that many ports were not distributable, even though they did not use the parts of the gettext port that had the conflicting license. And if any ports did use the parts of gettext that had the conflicting license, MacPorts would have allowed them to be distributed even though that is not legally permissible. Now that we have separate subports and each one can indicate its correct license and each other port can depend on the gettext subports it actually uses, the MacPorts distributability checks are correct. The license situation is explained more in ​this comment of PR 7399.

[ryandesign (Ryan Carsten Schmidt)]

Replying to tifrueh:

Note: Looking at the Arch Linux package I saw that libtextstyle is being disabled there, due to it depending on libcroco which is supposedly unmaintained and insecure. Might it be a good idea to do the same thing on MacPorts?

As it says in port info libtextstyle, "This library is part of gettext and a prerequisite for tools like msgfmt and friends". msgfmt is used by zillions of ports. In addition, bison depends on libtextstyle.

gettext used to have the ability to use an external (MacPorts) version of libcroco but that capability was removed from upstream gettext and the MacPorts gettext port with the 0.21.x update. I'm not familiar with libcroco or gettext's use of it. I do see that ​libcroco has been archived and I do see that ​the most recently filed bug report is a CVE that was not fixed upstream. The MacPorts libcroco port did get a patch for that CVE. I do not see that patch having been applied to the version of libcroco included in the gettext repository.

Please bring your concerns to the developers of gettext since they are the ones who would have to add the patch for the CVE or rewrite libtextstyle to use a different library if they agree that libcroco is insecure.

[tifrueh (Timo Früh)]

Oh, I see, that makes sense. Thanks a lot for the explanations.