[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: non-developer packages depending on gettext?

On Fri, 19 Oct 2012 23:20:39 +0700
Ivan Shmakov <oneingray@gmail.com> wrote:

> >>>>> Neil Williams <codehelp@debian.org> writes:
> […]
>  > Check if the package contains a shell script which supports
>  > translated output strings — such packages should Depend: gettext-base
>  > rather than drop the dependency entirely.
>  > I've had a quick look at gnas and it does seem that this is a case
>  > where gettext-base is required, but not gettext.
> 	ACK, thanks for the information.
> 	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.

This little wrinkle (an executable not being packaged in the binary
package of the same name) is probably the entire reason for why
packages end up with the wrong dependency.

It doesn't get picked up because, in most cases, it simply doesn't
matter enough. Having gettext and gettext-base installed is rarely
going to be an actual problem, it's merely an inconsistency.

>  > gettext should only be necessary for packages or tasks which
>  > *manipulate* PO files directly, rather than use the processed .mo
>  > files to generate translated output.  So, Build-Depends: yes,
>  > Depends: probably a bug.  gettext-base is only really needed when the
>  > package provides shell scripts with translated output because those
>  > evaluate the gettext process at runtime but that only requires
>  > gettext-base, not gettext.

.. and that evaluation in shell scripts uses /usr/bin/gettext in an
eval or similar but that still means a dependency on gettext-base *not*

>  > 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.

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.

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).


Neil Williams

Attachment: pgpbJtI0jPXrF.pgp
Description: PGP signature

Reply to: