[PATCH] Remove dependency from libintl in Samba4.

[Timur I. Bakeyev]

On Mon, Jun 08, 2009 at 09:27:30AM +1000, Andrew Bartlett wrote:
> On Sun, 2009-06-07 at 22:52 +0000, Timur I. Bakeyev wrote:
> > Hi all!
> > 
> > After some digging I figured out that this dependency comes from the
> > domestic version of Heimdal, that comes with Samba4. Honestly, I don't
> > believe that there is any real need for the l10n of the library, that
> > used only deeply internally.
> 
> Why?

Well, _I_ have multiple reasons for this, but not all of them would be
valid for the rest of the audience. So, just a few of a generic nature:

1. Every extra library, which is linked to the binary creates potential
problems with the versioning and dependency tracking. Each update of the
libintl triggs update of zillions of packages, that are made dependant on
it. I'm talking about source-based distributions here, like FreeBSD, for
example, and there it becomes nightmare to update all the soft.

2. Another problem with linking is created by the way, how Samba4
includes the found libraries. Basically, it tries hard to incorporate
EVERYTHING it was able to find cross the system. Contrary to the long
standing GNU software practice, when each --with|--enable flag has a
corresponding --without|--disable flag, in the current Samba4 configure
there is no way to disable unwanted features. If you happen to have
libintl in your system, it will be included, no matter what(yes, there
is a form of SMB_ENABLE(INTL,NO)) that should make the trick, but there
is no way to trigg it, AFAIK).

3. Having localized libraries is the worse idea ever, IMHO. I can
imagine, that UI could be quite useful when presented in the native
language for those who cant grasp English. But when it comes down to the
API - the only time the messages from it are exposed to the end user -
are the cases of some serious internal problems. And at that point it
should be meaningful to the developer, not end user. I guess, you don't
want to receive error report like:

msgid ""
"Heimdal requires the name of your local realm. This is typically your domain "
"name in uppercase. eg if your hostname is host.org.com, then your realm will "
"become ORG.COM. The default for your host is ${default_realm}."
msgstr ""
"Heimdal требует имя вашей местной области. Это обычно ваше доменное имя, "
"написанное прописными буквами. Напр., если имя вашего хоста host.org.com, "
"тогда вашей областью будет ORG.COM. Областью по умолчанию для вашего хоста "
"является ${default_realm}."

This is taken from Debian kdc.po, not exactly API message and it belongs to
deb-conf, not Heimdal itself. But related. I should also mention, that the
translation is very obscure, doesn't operate with the common practice terms
and in general more misleading, than helpful.

> > So, I suggest to disable inclusion of the libintl in the Samba4 configure.
> > 
> > Here is the proposed patch.
> 
> I disagree.  While Samba may have not yet gained good support in this
> area, why should we not use that support when present on the system?

I'm fine with Samba4 to get i18n support by itself, with the remark that
it can be disabled during compilation. But at the moment it doesn't have
any. When the time will come(if ever) - it can be added.

> It would also create another difference between Heimdal as used
> internally, and our hope to have a system Heimdal used in future.

And here we are comming to the most interesting part.

# find source4 -name \*.po

Gives NO results. There are just simply no PO files. Moreover,
distribution of the Heimdal 1.2.1 doesn't have them either! Neither does
it have --with-nls flag to the configure. Nor it has any references to
the libintl anywhere, besides few files which were generated by bison
and have HAVE_LIBINTL conditional include.

So, to me it seems that the whole addition of the libintl was a mistake
in a first place, caused by quick look through the code and noticeing
HAVE_LIBINTL condition. But it has no use and is automatically added by
bison to all generated files.

So, I still hope that we can drop unnecessary dependency.

With best regards,
Timur Bakeyev.