Michał Górny <mgo...@gentoo.org> wrote: > > 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_*?
Broken ebuilds are a reason to fix the ebuilds, but not a reason to replace a working concept by a hack which only works sometimes. > 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? You mean a user who emits --newuse when he only wants --changed-use and who sees the output of --ask, showing that the change is in LINGUAS="..." and nevertheless does not --exclude the package? In other words: Users who do not really know how to use portage? Well, I would recommend them to learn about the tools they use... > We're seriously talking about broken fix to a non-existent problem No, we are talking about removing a working solution (l10n.eclass) to return to a broken state which had caught me and probably many other users who manage systems with various linguas needs - until it was finally fixed at least for a certain number of packages by introducing the l10n eclass. > that actually introduces real problems s/introduces/solves/ like seeing that installation of a binary package conflicts with the machine's configuration. > How are you going to fix it? What should land in LINGUAS then? Leave LINGUAS unchanged for those packages which dont have linguas_* in their IUSE. Then still the packages which don't have IUSE=linguas_* are broken (because they have LINGUAS take effect without knowing of the user or the package manager), but at least those which currently use IUSE=linguas_* are working. > How would you determine the correct value? For ebuilds which are not updated to use IUSE=languas_* there is in principle no clean solution. Leave LINGUAS unchanged for these as a temporary hack until hopefully they are fixed some day. (Or change to l10n and modify l10n.eclass) >> > 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. Here we have the same opinion. The point is that LINGUAS is a variable which is not controlled by portage. This is the whole point of my argument: There must be a clean way to control this variable. The IUSE=linguas_* is one such clean way. Another way might be to make LINGUAS really a /var/db variable. > Yes, we know that all binary distributions were based on hacks for > years. Only Gentoo did it right [...] I do not understand what you mean here. I was not talking about binary distributions; maybe there is a misunderstanding. Maybe we have the same opinion: That INSTALL_MASK is some sort of hack; a very convenient one, but actually a hack. In any case it is not capable to do the "right" thing concerning linguas for every package; it only does it "right" for certain packages. >> 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? Any variable which is not under the package manager's control and which influences the building of the package is a problem. LINGUAS is one, CFLAGS is another one. For CFLAGS there is at least a variable in /var/db. >> 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. Not fixing the rest of the ebuild is not an excuse to remove a mechanism which made at least those ebuilds work for which the maintainers took the time to fix them (by using l10n.eclass or doing an analogous thing manually). >> 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. I was not talking about "your arguments" but about your specific argument "we must remove a working mechanism because an ebuild author might do a mistake and e.g. bump without checking the changes of the package". > When people don't get needed locales installed, it's a non-problem. Who said this? This is exactly the issue I am talking about with binary packages: > *Every* binary package is valid because it doesn't have anything > stripped. This is not true. If you compiled the binary package with LINGUAS="en_US de_DE" and install it on a laptop with LINGUAS="en_US de_DE cz_CZ", you will be missing the Czech translations, because they are not in the binary package. (They are not "stripped" but simply not there...) So binary package compiled with LINGUAS="en_US de_DE" might simply not be valid on a machine which has LINGUAS="en_US de_DE". Well, the majority of packages probably still *is* valid, because the majority of packages probably doesn't provide a Czech translation. That's why it should be known to the package manager which LINGUAS setting have been used, and - at least for hopefully as many packages as possible - which LINGUAS are actually supported by the package. The current solution with IUSE=linguas_* did this job very well. > That's why you are not supposed to use it. Simple enough. So you want to remove *completely* the possibility to use the LINGUAS settings of some packages. Well, not remove it, but only allow it in future as hack for users who are then obliged to do the job of the package manager manually and without any support. What are again the reasons for removing the working solution with IUSE and showing the gentoo users the obscene stinky finger? That removing it makes things simpler? For the package manager maybe yes. For the user of course not. As always: Removing features always apparently simplifies things. Except for those who use these features. > 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. Then why do you claim that l10n.eclass (which then of course must be updated to treat IUSE=l10n_* in the way it does currently with instead of IUSE=linguas_*) should be removed? l10n.eclass together with export LINGUAS=$L10N should be exactly the right behaviour for all packages currently supporting IUSE=linguas_*. Why should this perfectly working thing (at least for those ebuilds which support it) now be removed? What would be the benefit for the user? I see only the disadvantage that some users now have to do the job of the package manager even for these packages...
