[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Martin Vaeth]

Michał Górny <mgorny@g.o> 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.