Re: news/pan and mk/tools/gettext.mk

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sat, Nov 17, 2018 at 07:03:29PM +0100, Rhialto wrote:
> On Fri 16 Nov 2018 at 22:11:14 +0100, Joerg Sonnenberger wrote:
> [about using the pkgsrc version of gettext-tools, which depends on
> gettext-libs, which includes libintl, which must not be linked into the
> same program as the base system libintl]
> 
> > It still ensure that the library is installed and that one can create
> > various fun. Little reason for that given that the two files are
> > essentially static.
> 
> That is true, but only in the build environment. In the runtime
> environment, the intl library isn't there. (This is assuming that one
> uses binary packages somehow, either downloaded, or built in pkg_comp,
> or something along those lines).

That's an assumption that is simply not true for many users.

> The problem with pre-generating some files and adding them to files/ is
> that it doesn't scale.

Given the amount of packages that depend on this stupid feature so far,
I don't see that as problem. I have no idea why they insist on
maintaining the same string in twenty different files when the
problematic files *already* allow placing the strings once. Given that
the content doesn't really change like ever, the gettext tools don't
help at all.

> msginit --no-translator -l en -i lynx.pot
> /bin/sh: Can't open /usr/share/gettext/project-id
> msginit: /usr/share/gettext/project-id subprocess I/O error
> Created en.po.

*sigh* This is stupid too. No further comment.

> In fact there seem to be lots of other packages which may have the same
> risk of inadvertently linking in the pkgsrc libintl. Candidates to look
> at and probably make consistent are (as found by grep gettext-tools):
> 
>     cad/pcb, cad/geda, which DEPEND on gettext-tools;

We are already discussing those.

>     devel/quilt which USE_TOOLS it;

This one is not so much about msgfmt, but the gettext shell tool.

>     finance/gnucash, x11/gtk3 which TOOL_DEPENDS on it;

Likely the same bullshit etc.

> "Fixing" all of these by adding the burden of pre-generating some files
> for them for each version update on the respective maintainers doesn't
> sound good to me.

Slap the maintainer into not pointlessly requiring full modern gettext
sounds like a perfectly reasonable approach to me. Heck, that's exactly
how gettext was supposed to be usable...

Joerg