Dnia 1 czerwca 2016 11:23:09 CEST, Martin Vaeth <mar...@mvath.de> napisał(a): >Michał Górny <mgo...@gentoo.org> wrote: >> >> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it >> in Portage. > >As already mentioned by some, INSTALL_MASK is something else than >LINGUAS, because LINGUAS involves also files which are generated >by the build system. Although I appreciate a more configurable >INSTALL_MASK, this should not be mixed with the LINGUAS problem.
LINGUAS will be passed through from the environment so nothing is lost. > >> 2. Introduce a new USE_EXPAND that can be used to control >localizations >> whenever this is really required (dependencies, large files, etc.). >> Let's use L10N as a draft name for it. > >Just to be sure that there is no misunderstanding: >L10N should take the role which LINGUAS currently has for most >packages from the user perspective. >In other words, all ebuilds for packages whose build systems treat >LINGUAS in a clean way (not relying on order etc.) >and which currently have IUSE=linuguas_* will very likely contain >corresponding ISUE=l10n_* and the line > >export LINGUAS=$L10N > >Therefore, I suggest to put this line in l10n.eclass >(perhaps with a mechanism to avoid it for some exceptional packages >which have to treat LINGUAS differently.) >This way, none of these ebuilds inheriting l10n needs to be patched. This eclass should be killed with fire as ugly nonsense that makes some packages useless for binary packages. As far as I'm concerned, it may not exist, be broken or whatever. As for LINGUAS, it should be left as a toy for advanced users and not presented as a recommended solution. > >> 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting >> to L10N or by removing the needless flags. > >I would strongly discourage doing the latter (unless IUSE=linguas_* >was there only by mistake): When users change their L10N (or >USE-flags), users should be able to see which packages need a >recompilation when using emerge -N. Also for binary packages, it >must be easily possible to see changes. >See the more lengthy explanation below. > >> Request changing LINGUAS to L10N in make.conf, > >+ > >> and make LINGUAS considered an 'advanced variable' for >> implicit localization control (i.e. passed through to build systems). > >With only some rare exceptions (e.g. where the order matters), >ebuilds should better set this variable according to IUSE=l10n_*. >It would be better if these exceptions would not have to exist >at all, i.e. if e.g. the ebuilds for packages for which the order >of LINGUAS matters also use IUSE=l10n_* and introduce other >USE flags to specify the order somehow (AFAIK only mplayer is >involved, and for this only the first item is important, so that >one can introduce e.g. IUSE=default_l10n_* variables for which exactly >one must be set, or something similar.) >Indeed, these exceptions are very inconvenient for the user >as well as for the package manager: > >1) In contrast to packages with L10N, the user cannot see with >tools like eix for which linguas a certain package is installed. >In fact, the user would have to analyze the compressed environment >file find this out (this is also very package manager specific): What's the use of this? Most of the packages don't have the flags anyway. For those who have, you can't trust them being up-to-date. As for installed package, all files are listed in vdb (including those masked), so you can easily figure out the differences. In fact, app-portage/install-mask supports rebuilding due to IM changes for a long time. > >2) Even worse for binary packages. Wrong. All localizations are included in the binary package, so it's perfectly reusable across all systems. Of course, as long as maintainer doesn't start playing with LINGUAS. > >3) The package manager cannot see after a change of LINGUAS, >which packages need a recompilaten. Wrong, as already explained above. > >4) The same for binary packages. Likewise. > >> Recommend clean INSTALL_MASK solution instead. > >I would also not mix these unrelated things in the documentation. >One can hint that this takes additional actions for build >systems not honouring L10N correctly, but usually it is >not a substitute for setting L10N (or LINGUAS for the >exceptional packages) but only a supplement. -- Best regards, Michał Górny (by phone)
