[Buildroot] [PATCH v3 0/2] Add gettext-tiny package

[Vadim Kochan]

Hi Thomas!

On Sat, Mar 09, 2019 at 11:37:42PM +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 12 Feb 2019 23:55:18 +0200
> Vadim Kochan <vadim4j at gmail.com> wrote:
> 
> > Add lightweight alternative for the GNU gettext package - gettext-tiny.
> > The sources are used from sabotage-linux project. Some files are used
> > from the original gettext gnu like po/*, gettextize and some m4 files.
> > 
> > The original gettext package is renamed to gettext-gnu because now gettext is
> > a virtual package and gettext-gnu and gettext-tiny became as gettext providers.
> > 
> > The main purpose of gettext-tiny is to be used only for the host if NLS
> > is not enabled.
> 
> I finally took some time to play around with this. The first thing is
> that I didn't like a lot the download of lots of gettext-gnu files from
> gettext-tiny. I've played a bit with this, and ended up trying to use
> the gettext-gnu tarball instead. See:
> 
>   https://github.com/tpetazzoni/buildroot/tree/gettext-tiny
>   https://github.com/tpetazzoni/buildroot/commit/22936b22944f49646c8732fb2742a526d0a556e2#diff-e5eacf305a325109262748204673e7b5R19
> 
> for the details. It also avoids the need to patch to get config.rpath,
> because config.rpath is available in the gettext-gnu tarball.
> 
> I also reworked how the virtual package was handled, but I then
> understood that I had mistaken that only the host package was really a
> virtual package with two implementation: the target gettext package has
> only one implementation: gettext-gnu.
> 
> However, the ecryptfs-utils case has shown that it is possible for a
> package to need a gettext implementation even if BR2_SYSTEM_ENABLE_NLS
> is disabled. So from there, we have two solutions:
> 
>  - Patch ecryptfs-utils itself so that it doesn't use gettext when
>    --disable-nls is used. Perhaps this is the right thing to do. In
>    this case, we could indeed mandate that the target gettext package
>    is only available when BR2_SYSTEM_ENABLE_NLS=y, and therefore indeed
>    have the gettext virtual package always point to gettext-gnu.
> 
>  - Alternatively, support gettext-tiny as a target package, which would
>    provide both libintl and the gettext program (the latter to please
>    ecryptfs-utils).
> 
> I was initially worried that some packages that don't understand
> --disable-nls might try to link with libintl, and that we would
> therefore need a target gettext package even if BR2_SYSTEM_ENABLE_NLS.
> However, libintl is only a replacement library for the gettext
> functions that don't exist in uclibc/musl, but do exist in glibc.
> Because in glibc they are part of the C library itself, I don't think
> any package is ever going to link explicitly with libintl. It's only
> Buildroot that ensures -lintl is passed to the LIBS/LDFLAGS when
> needed. So I believe we're good.
> 
> So, perhaps the good solution is option (1) above ?

Many thanks for your feedback! Using the gnu gettext's tar is really better
idea! Regarding ecryptfs-utils - yes, I think the patch might be really easy,
something like this:

...
function trans {
    if command -v gettext &> /dev/null; then
        gettext @
    else
        echo @
    fi
}
...

and replace gettext -> trans in scripts.

Regards,
Vadim Kochan