upstream ./configure script supports --enable-nls/--disable-nls, so ebuild may/must support USE=nls as well... Reproducible: Always
Created attachment 336862 [details, diff] add 'nls' USE flag to ebuild
What is the benefit of disabling nls in networkmanager? Consider that: 1. networkmanager depends on packages like glib that require nls support; and 2. even if we add the nls USE flag, networkmanager will continue to depend on gettext and intltool when USE=-nls because gettext's and intltool's autotools macros will still be needed at build time for eautoreconf.
(In reply to comment #2) > What is the benefit of disabling nls in networkmanager? > > Consider that: > 1. networkmanager depends on packages like glib that require nls support; and > 2. even if we add the nls USE flag, networkmanager will continue to depend > on gettext and intltool when USE=-nls because gettext's and intltool's > autotools macros will still be needed at build time for eautoreconf. Consider this: 1. in configs I have -nls for all my packages and LINGUAS: -* 2. and anyway I have a lot of unused crap in /usr/share/locale/??/LC_MESSAGES/*.mo and btw, autotools based packages (at least a good one) designed in a way that tarball is independed on autotools (self-sufficient)... so you don't need 'em to build. and I strongly believe that packages use gettext also DO NOT REQUIRE gettext after they was `gettexize`d -- they become self-sufficient as well... yep, I understand that ebuilds sometime do reconfigure (execute aclocal+autoconf+automake+autoheader)... but I'm not sure they exec `gettextize` to 'inject' current version of gettext into a package while ebuild it -- I'm not sure that is as safe as in case of autoconf/automake/libtool. do you?
(In reply to comment #3) If the only reason you want the nls USE flag is to avoid installing translations that you don't need, then the correct solution is to set LINGUAS="en" in your make.conf file. Then networkmanager (as well as 95% of other intltool-based packages) won't install any non-English translation files. So adding a new USE flag is not needed in this case. If you do encounter a package that ignores LINGUAS and installs extra translations, please file a new bug about it and have it block bug #405485. > yep, I understand that ebuilds sometime do reconfigure (execute > aclocal+autoconf+automake+autoheader)... but I'm not sure they exec > `gettextize` to 'inject' current version of gettext into a package while > ebuild it -- I'm not sure that is as safe as in case of > autoconf/automake/libtool. do you? They do (see /usr/portage/eclass/autotools.eclass) and yes, in my experience it is safe - virtually all autoreconf bugs are caused by incompatibilities between different versions of GNU automake and the remaining few are caused by GNU libtool; I remember only one case where an update to a third-party aclocal macro caused any issues.
(In reply to comment #4) > (In reply to comment #3) > > If the only reason you want the nls USE flag is to avoid installing > translations that you don't need, then the correct solution is to set > LINGUAS="en" in your make.conf file. > default language for all programs I have in my gentoo system is already English, so why would I install smth else? I won't have a code from gettext in that programs at all! I've satisfied w/ default translation, so why would I compile any package w/ LINGUAS: en and have a code to load '*.mo' file and lookup into tables for strings? -- I just don't need this code in all `gettextize`d applications > Then networkmanager (as well as 95% of other intltool-based packages) won't > install any non-English translation files. So adding a new USE flag is not > needed in this case. but definitely it would be needed for other cases... when someone have particular LINGUAS and got "a lot of others, for free"... if follow your reasons, then every package w/ nls USE flag actually don't need it... huh, it depends on gettext anyway, so why to have it???
(In reply to comment #5) > if follow your reasons, then every package w/ nls USE flag actually don't > need it... huh, it depends on gettext anyway, so why to have it??? The nls USE flag makes sense for core system packages because they may be used on embedded systems with uclibc or other non-GNU libc implementations that don't have libintl, and where every kilobyte of RAM and flash matters. For desktop- and server-oriented packages, USE=nls is usually superfluous, IMHO.
(In reply to comment #6) > (In reply to comment #5) > > if follow your reasons, then every package w/ nls USE flag actually don't > > need it... huh, it depends on gettext anyway, so why to have it??? > > The nls USE flag makes sense for core system packages because they may be > used on embedded systems with uclibc or other non-GNU libc implementations > that don't have libintl, and where every kilobyte of RAM and flash matters. > > For desktop- and server-oriented packages, USE=nls is usually superfluous, > IMHO. not only embedded... if I'm trying to make a bootable gentoo system on 512M USB flash (w/ graphic desktop), every M and even K matter as well...
(In reply to comment #7) > not only embedded... if I'm trying to make a bootable gentoo system on 512M > USB flash (w/ graphic desktop), every M and even K matter as well... Then you would be happy to know that networkmanager with "--enable-nls LINGUAS=en" and with "--disable-nls" take *exactly* the same amount of space (7336K with my flags). If you are trying to save space by disabling nls, you need to start by using a libc without libintl (e.g. klibc or a basic uclibc configuration) and then disable nls in *all* of your packages; disabling it in just one (networkmanager) won't save you any space. And this is something that is basically impossible if you are going for a reasonable graphical desktop - because a modern graphical desktop is certain to include packages that won't run on a minimal embedded-style libc.
