Re: non-developer packages depending on gettext?
>>>>> Neil Williams <codehelp@debian.org> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> wrote:
>>>>> Neil Williams <codehelp@debian.org> writes:
[…]
>> To note is that Source: gnunet has contrib/report.sh, which calls
>> gettext(1), but it doesn't seem to be propagated to any of the
>> binaries currently depending on gettext.
> You've misunderstood the gettext packaging.
> $ dpkg -S `which gettext`
> gettext-base: /usr/bin/gettext
> So packages/scripts which call gettext should not depend on gettext
> but on gettext-base instead — that's the point.
The point is that I haven't checked for gettext(1) the first
time I've examined the gnunet source package. So, even though I
was sure that the dependency on gettext was unwarranted, I
didn't actually rule out gettext-base.
[…]
>>> Could be worth filing a wishlist bug against lintian because it
>>> should be quite easy to spot.
>> ? I see no easy way to discern between these three cases (the
>> dependency is valid, depend on gettext-base instead, drop the
>> dependency altogether.)
> 0: Manipulating PO files directly should only happen during package
> builds, so either the package is itself a build tool (like po4a) or
> the dependency goes into Build-Depends.
I understand the logic. What I can't understand is how to
implement it as a lintian check. (There isn't really a “this
package is a build tool” flag. There're Tags:, but they may
be misleading; consider, e. g., gnuplot bearing suite::gnu.)
> 1: Depend on gettext-base but not gettext when the package calls
> /usr/bin/gettext, dgettext and/or ngettext directly (all from
> gettext-base) rather than the other executables in the gettext binary
> package which do stuff like manipulating or reporting on PO files.
I don't see an easy way to check for calls to gettext(1), etc.,
either. Certainly, we can grep the source, but how reliably
(and specific) would that be for a lintian check?
> 2: Drop any dependency when no calls to gettext can be found in the
> source and it isn't a build tool. Languages other than shell have
> in-built ways of using the .mo file prepared through PO and gettext
> to output translated text at runtime. This has nothing to do with
> running gettext itself. Languages may also have their own packaging
> support for this, e. g. liblocale-gettext-perl (which itself uses the
> libc support, not gettext-base).
So, at least we could safely warn about a dependency on
gettext-base for a package containing no Shell scripts.
Still, it doesn't seem to rule out a dependency on gettext.
--
FSF associate member #7257
Reply to: