tech-pkg archive

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

Re: nls support



Le 2019-10-25 09:02, Frédéric Fauberteau a écrit :
Hi folks,

I found 1015 packages that contains files in share/locale,
approximately 5% of our packages:
$ find pkgsrc/ -type f -name PLIST -exec grep -q "share/locale" '{}'
\; -print | wc -l
1015

There are apparently 35 packages that provide nls option enabled by default:
$ grep -r "PKG_SUGGESTED_OPTIONS.*nls" * | wc -l
35

And apparently 28 packages that provide this option disabled by default:
$ grep -r "PKG_SUPPORTED_OPTIONS.*nls" * | wc -l
28

I am personally in favour of adding a nls option to packages that
provide localization file because it moves stuffs like LDFLAGS.FooOS+=
-lintl or CONFIGURE_ENV+= gt_cv_func_gnugettextX_libintl=yes out of
the Makefile and it makes it clearer. If every localized packages have
a nls option, we could choose a policy: either (i) nls is in
PKG_SUPPORTED_OPTIONS or nls (ii) is in PKG_SUGGESTED_OPTIONS. I
prefer (i) for my servers and (ii) for my desktop, then I have no
strong opinion on what should be a default policy.

I would like to know the opinion of the community. Should we offer set
of packages that are properly localized by default or not?

Please Adam, let me cite your words answering to the question if nls should be enabled by default for databases/postgresqlXX:
IMHO the package must be as complete as possible, so people can download a binary package and do not have to recompile it manually when they need the NLS strings, for example.

Please, turn the nls option on.

Thanks :)
Adam

I agree with that. And I could build my bulk for my own servers with PKG_DEFAULT_OPTIONS+= -nls.

Home | Main Index | Thread Index | Old Index