Michał Górny <mgo...@gentoo.org> wrote: >> >>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.
Exactly the opposite is the case: Letting a variabe like LINGUAS "hiddden from the package manager" decide about the actual content of the package makes any handling of binary packages broken. The introduction of linguas_* (and of the l10n eclass to make this handable for the ebuild writer) was finally fixing this long-broken behaviour of ebuilds. You now want to revert this fix and return to the earlier broken state without any need. If the only reason for the "need" is a badly formulated/thought-through EAPI=5/6 specification to clean LINGUAS for packages not having it in its IUSE, then please fix this specification or make at least an exception for LINGUAS, but don't break the working solution. > As for LINGUAS, it should be left as a toy for advanced users Selecting the languages which a package supports is an option only for advanced users? You must be kidding! > and not presented as a recommended solution. The "recommended solution" is to rely on a hack which removs files behind the back of upstreams installation program (which likely installs other random language data in random files for various languages)? You are kidding again! >>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? That the package manager (and the user) is well aware of the options actually used to compile/install the package. Not hiding the user-selected configuration behind the package manager and the user in some random variable. > Most of the packages don't have the flags anyway. Then fix the package not handling LINGUAS in a sane way yet. > For those who have, you can't trust them being up-to-date. That's a non-argument. No ebuild you can trust being up-to-date as well as all ebuilds. > As for installed package, all files are listed in vdb > (including those masked), so you can easily figure out the > differences. So to find out whether a binary package is valid for the current configuration (i.e. the current LINGUAS), the package manager or user "just" has to recompile it and compare the files and checksums. Great! And because this reinstallation-solution is possible, it is ok to rely on a hack instead of a solution visible to the package manager and user. >>2) Even worse for binary packages. > > Wrong. All localizations are included in the binary package, but not in the metadata. > Of course, as long as maintainer doesn't start playing with LINGUAS. That's the point: As long as all systems and all packages have the same LINGUAS settings. Which is not the case for many users having various systems. E.g. for a laptop, it is very natural to have different LINGUAS than for a desktop, even if you likely compile for the laptop on the desktop. >>3) The package manager cannot see after a change of LINGUAS, >>which packages need a recompilaten. > > Wrong, as already explained above. So? How can you see it? By checking hackishly the existence of random files in */po/* while e.g. the actual effect of LINGUAS is in some error message provided by the package in god-knows-what manner? *If* you want to keep only LINGUAS and not introduce L10N, *then* at least you should make LINGUAS a metadata variable to be stored in /var/db so that the user and package manager can easily access it.
