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

[Michał Górny]

On Wed, 1 Jun 2016 16:27:16 +0000 (UTC)
Martin Vaeth <martin@×××××.de> wrote:

> 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.

Do you have any numbers on how many ebuilds were exactly being fixed?
And how many were broken in the process because someone failed to
update linguas_*? How do you feel about the lot of Chromium users who
spent a few hours rebuilding it to discover that they did only for
a linguas_* flag change they didn't even care for?

We're seriously talking about broken fix to a non-existent problem that
actually introduces real problems (and the incidental locale removal
is the least of those problems).

> 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.

How are you going to fix it? What should land in LINGUAS then? How
would you determine the correct value? How would you apply package.use
with flags that don't exist?

> > 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!

No, implicitly stripping installed files via insecure mechanism that
is outside of package manager control is.

> > 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!

Yes, we know that all binary distributions were based on hacks for
years. Only Gentoo did it right by enabling quirks that incidentally
caused files not to be installed without knowing which files were
actually omitted. Except when they didn't. Or maybe they did.

> >>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.

It's as random as LINGUAS. Your point?

> > Most of the packages don't have the flags anyway.
>
> Then fix the package not handling LINGUAS in a sane way yet.

I'm not sure if you are aware of it but most of us is not getting paid
for working on Gentoo. So thank you, I'd rather not get another huge
amount of work for minor benefit of a few vocal users who can't stand
not having every single possible useless choice pretty printed on top of
every single package.

So how about you do it? I'm going to complain if you get around 80% of
ebuild fixed for this, and guarantee that the flags will always be
up-to-date.

> > 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.

Of course. Your arguments are important arguments, mine are
non-arguments. When people don't get needed locales installed, it's
a non-problem. When they get extra files on their precious hard drives,
it's a huge issue.

> > 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.

I don't even understand what you're trying to imply.

*Every* binary package is valid because it doesn't have anything
stripped. It's stripped while the package is installed. That's how
INSTALL_MASK works.

And as I already pointed out, it *is* visible to the package manager
because it records it. It's real data. There. In the files. Seriously.

> >>2) Even worse for binary packages.
> >
> > Wrong. All localizations are included in the binary package,
>
> but not in the metadata.

Your point?

> > 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.

That's why you are not supposed to use it. Simple enough. Then you have
reusable binary packages that can get fitted to the target system using
INSTALL_MASK.

> >>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.

Why are you making some random assumptions that I'm going to do exactly
the opposite of what I've proposed?

If LINGUAS is marked as advanced variable you're not supposed to use,
I don't care about its side effects. I care about L10N and files
stripped via INSTALL_MASKs. If you use LINGUAS, you're on your own.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>