* On 2024-05-06 at 22:43 BST, Greg Troxel wrote:
However, I still think we should discuss "should we add an nls option to everything" rather than it just happening. The nature of changes is that if 9/10 think it shouldn't happen and don't do it, and 1/10 think it should, it ends up happening, and I don't think our project should work that way. I have no idea who thinks what in this case, but that's what raising large scale changes for discussion is all about. If it happened (I've been distracted lately), sorry for missing it.
It's important to remember that adding PKG_OPTIONS exponentially increases the number of configurations a packager must test when updating a package. This is even more critical when the option adds PLIST variables.
Historically I don't think people have time for this, and so we end up seeing a reasonable amount of fallout where packages are left broken after updates. I'd argue this is much worse than having support for the option in the first place.
For this reason I'm generally not a fan of adding too many PKG_OPTIONS, and would prefer to see them used primarily where a package has mutually exclusive options that the user must select between, and in other cases we simply ship packages that cater to the widest number of user cases, and keep things as simple as possible.
With nls specifically, the only time I really see a benefit in having the option is when a package is in the bootstrap path of core tools or a compiler, and being able to disable nls avoids circular dependencies, e.g.:
https://github.com/NetBSD/pkgsrc/commit/70ca42fbf8ccadc39a1a5a1d86d8b523e2f6d6f1Other than that I don't really see the benefit. The files are tiny, and you're going to have a gettext dependency at some point.
tl;dr: I'm not hugely fussed if you want to add them, the patch for automatic handling looks reasonable at first glance, but if the work results in any broken package updates I will be very very sad.
-- Jonathan Perkin - mnx.io - pkgsrc.smartos.org Open Source Complete Cloud www.tritondatacenter.com