gettextize jeszcze raz

[Jakub Bogusz]

Nadal nic nie zostało ustalone (jak zwykle), w specach lądują różne
rozwiązania, a w rpm.macros na HEAD jest zwalone %{__gettextize}, nie
nadające się do użytku w najnormalniejszym przypadku (nowy gettext +
pakiet dostosowany do nowego gettexta - np. coreutils.spec).
Tym razem nie chcę już wymieniać co chwila wersji gettexta do budowania
nowych pakietów i potrzebuję spójnego rozwiązania, żeby potem nie
odkręcać.

Rozwiązania są takie:
1. zachowanie normalnego %{__gettextize}="gettextize --copy --force"
oraz dodanie %{gettextize_compat} z jakimiś ifami dla starych
pakietów (coś jak %{__gettextize} z rpm.macros z HEAD)
Zaleta: widać od razu w specu co jest dostosowane do nowego gettexta,
a co wymaga jakichś hacków
Wada: trzeba zmieniać wszystkie spece do starych pakietów

2. Dodanie więcej ifów do %{__gettextize} i czasem konieczność dodania
dodatkowych ifów, żeby zbudować pakiet przystosowany do nowego gettexta
w sposób nie przewidziany przy pisaniu istniejących już warunków

Jeżeli już (2), to czy wspierać jeszcze gettexta 0.10? (po co?)

Bez wsparcia dla 0.10 wyglądałoby to jakoś tak:

%__gettextize { \
    if grep -q -s 'AM_GNU_GETTEXT(.*external.*)' configure.{in,ac} ; then \
        gettextize --copy --force; \
    then
        gettextize --copy --force  --intl; \
        if [ -f po/Makevars.template -a ! -f po/Makevars ]; then \
            cp -f po/Makevars{.template,}; \
        fi; \
    fi; \
}

Oczywiście w przypadkach, kiedy katalog nie nazywa się "po", a "i18n" albo
"locale", trzeba to cp robić ręcznie.


-- 
Jakub Bogusz    http://www.cs.net.pl/~qboosh/