On Wed, 1 Jun 2016 16:27:16 +0000 (UTC) Martin Vaeth <mar...@mvath.de> wrote:
> 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. 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/>
pgpxaEFXGbi9_.pgp
Description: OpenPGP digital signature
