Re: find_lang

On Jan 24, 2012, at 3:29 PM, Alexander Khryukin wrote:

> 
> 
> thread bump.
> 
> I have same error.
> 
> Package: wesnoth
> In output i have a lot of *.mo files
> but macro 
> 
> %find_lang %{name} --all-name
> 
> %files -f %{name}.lang
> 
> not working.
> How to fix it?
> 

Well I'm sure Per Oyvind is likely going to fix Real Soon Now.

Meanwhile its just a script that breaks from time to time for lots
of reasons.

If all else fails, and you need to get a package built *now*, and can't wait for
the "proper" fix for some reason:

1) Look at the %find_lang macro. Its just a template to invoke a convenience script:
            rpm --showrc | grep find_lang

2) Expand the macro template either mentally or doing
             rpm --eval '%find_lang %{name} --all-name'
     Note that a --eval will have side effects and run other scripts; in the case of %find_lang
     the consequences are likely minor (it will generate a %name.lang file in the current directory)

3) Grab a copy of the script and fix as needed: the script is usually in /usr/lib/rpm/find_lang.sh
     by default, sometimes is elsewhere depending on how a build system configures rpm.

4) Put a copy of the script into a SourceN: directive (choosing N as appropriate):
            SourceN: find_lang.sh
    Every SourceN: directive also silently defines a %{SOURCEn} macro with full path
    (and N == n chosen appropriately)

5) Replace the %find_lang macro in the *.spec with its expansion from step 2). Instead
     of using the hardwired path to the script, substitute %{SOURCEn}.

6) Send the "… fix as needed …" patch from step 3) to Per Oyvind (who will likely
     say "Thank you!".

All I'm saying is that %find_lang is nothing more than a convenience wrapper
to invoke a mostly simple script. Most of the conventional uses of macros in *.spec recipes
are little more than convenience wrapper templates for common tasks in most cases.

And scripts break because … well … they are scripts.

hth

73 de Jeff