1 |
Michał Górny <mgorny@g.o> wrote: |
2 |
> |
3 |
> Do you have any numbers on how many ebuilds were exactly being fixed? |
4 |
> And how many were broken in the process because someone failed to |
5 |
> update linguas_*? |
6 |
|
7 |
Broken ebuilds are a reason to fix the ebuilds, but not a reason |
8 |
to replace a working concept by a hack which only works sometimes. |
9 |
|
10 |
> How do you feel about the lot of Chromium users who |
11 |
> spent a few hours rebuilding it to discover that they did only for |
12 |
> a linguas_* flag change they didn't even care for? |
13 |
|
14 |
You mean a user who emits --newuse when he only wants --changed-use |
15 |
and who sees the output of --ask, showing that the change is in |
16 |
LINGUAS="..." and nevertheless does not --exclude the package? |
17 |
In other words: Users who do not really know how to use portage? |
18 |
Well, I would recommend them to learn about the tools they use... |
19 |
|
20 |
> We're seriously talking about broken fix to a non-existent problem |
21 |
|
22 |
No, we are talking about removing a working solution (l10n.eclass) |
23 |
to return to a broken state which had caught me and probably many |
24 |
other users who manage systems with various linguas needs - |
25 |
until it was finally fixed at least for a certain number of packages |
26 |
by introducing the l10n eclass. |
27 |
|
28 |
> that actually introduces real problems |
29 |
|
30 |
s/introduces/solves/ |
31 |
like seeing that installation of a binary package conflicts |
32 |
with the machine's configuration. |
33 |
|
34 |
> How are you going to fix it? What should land in LINGUAS then? |
35 |
|
36 |
Leave LINGUAS unchanged for those packages which dont have linguas_* |
37 |
in their IUSE. |
38 |
Then still the packages which don't have IUSE=linguas_* are broken |
39 |
(because they have LINGUAS take effect without knowing of the |
40 |
user or the package manager), but at least those which currently |
41 |
use IUSE=linguas_* are working. |
42 |
|
43 |
> How would you determine the correct value? |
44 |
|
45 |
For ebuilds which are not updated to use IUSE=languas_* |
46 |
there is in principle no clean solution. Leave LINGUAS unchanged |
47 |
for these as a temporary hack until hopefully they are fixed |
48 |
some day. (Or change to l10n and modify l10n.eclass) |
49 |
|
50 |
>> > As for LINGUAS, it should be left as a toy for advanced users |
51 |
>> Selecting the languages which a package supports is an option |
52 |
>> only for advanced users? You must be kidding! |
53 |
> |
54 |
> No, implicitly stripping installed files via insecure mechanism that |
55 |
> is outside of package manager control is. |
56 |
|
57 |
Here we have the same opinion. The point is that LINGUAS is a |
58 |
variable which is not controlled by portage. This is the whole |
59 |
point of my argument: There must be a clean way to control this |
60 |
variable. The IUSE=linguas_* is one such clean way. |
61 |
Another way might be to make LINGUAS really a /var/db variable. |
62 |
|
63 |
> Yes, we know that all binary distributions were based on hacks for |
64 |
> years. Only Gentoo did it right [...] |
65 |
|
66 |
I do not understand what you mean here. |
67 |
I was not talking about binary distributions; maybe there is a |
68 |
misunderstanding. |
69 |
Maybe we have the same opinion: That INSTALL_MASK is some sort of hack; |
70 |
a very convenient one, but actually a hack. |
71 |
In any case it is not capable to do the "right" thing concerning |
72 |
linguas for every package; it only does it "right" for certain |
73 |
packages. |
74 |
|
75 |
>> That the package manager (and the user) is well aware of the |
76 |
>> options actually used to compile/install the package. Not hiding |
77 |
>> the user-selected configuration behind the package manager and |
78 |
>> the user in some random variable. |
79 |
> |
80 |
> It's as random as LINGUAS. Your point? |
81 |
|
82 |
Any variable which is not under the package manager's control |
83 |
and which influences the building of the package is a problem. |
84 |
LINGUAS is one, CFLAGS is another one. For CFLAGS there is at |
85 |
least a variable in /var/db. |
86 |
|
87 |
>> Then fix the package not handling LINGUAS in a sane way yet. |
88 |
> |
89 |
> I'm not sure if you are aware of it but most of us is not getting paid |
90 |
> for working on Gentoo. |
91 |
|
92 |
Not fixing the rest of the ebuild is not an excuse to remove a |
93 |
mechanism which made at least those ebuilds work for which the |
94 |
maintainers took the time to fix them (by using l10n.eclass |
95 |
or doing an analogous thing manually). |
96 |
|
97 |
>> For those who have, you can't trust them being up-to-date. |
98 |
>> That's a non-argument. No ebuild you can trust being |
99 |
>> up-to-date as well as all ebuilds. |
100 |
> |
101 |
> Of course. Your arguments are important arguments, mine are |
102 |
> non-arguments. |
103 |
|
104 |
I was not talking about "your arguments" but about your specific |
105 |
argument "we must remove a working mechanism because an ebuild |
106 |
author might do a mistake and e.g. bump without checking the |
107 |
changes of the package". |
108 |
|
109 |
> When people don't get needed locales installed, it's a non-problem. |
110 |
|
111 |
Who said this? This is exactly the issue I am talking about with |
112 |
binary packages: |
113 |
|
114 |
> *Every* binary package is valid because it doesn't have anything |
115 |
> stripped. |
116 |
|
117 |
This is not true. If you compiled the binary package with |
118 |
LINGUAS="en_US de_DE" and install it on a laptop with |
119 |
LINGUAS="en_US de_DE cz_CZ", you will be missing the Czech |
120 |
translations, because they are not in the binary package. |
121 |
(They are not "stripped" but simply not there...) |
122 |
So binary package compiled with LINGUAS="en_US de_DE" might |
123 |
simply not be valid on a machine which has LINGUAS="en_US de_DE". |
124 |
Well, the majority of packages probably still *is* valid, |
125 |
because the majority of packages probably doesn't provide a Czech |
126 |
translation. |
127 |
That's why it should be known to the package manager which |
128 |
LINGUAS setting have been used, and - at least for hopefully |
129 |
as many packages as possible - which LINGUAS are actually |
130 |
supported by the package. |
131 |
The current solution with IUSE=linguas_* did this job very well. |
132 |
|
133 |
> That's why you are not supposed to use it. Simple enough. |
134 |
|
135 |
So you want to remove *completely* the possibility to use the |
136 |
LINGUAS settings of some packages. Well, not remove it, but only |
137 |
allow it in future as hack for users who are then obliged to do |
138 |
the job of the package manager manually and without any support. |
139 |
|
140 |
What are again the reasons for removing the working solution |
141 |
with IUSE and showing the gentoo users the obscene stinky finger? |
142 |
That removing it makes things simpler? |
143 |
For the package manager maybe yes. For the user of course not. |
144 |
As always: Removing features always apparently simplifies things. |
145 |
Except for those who use these features. |
146 |
|
147 |
> Why are you making some random assumptions that I'm going to do exactly |
148 |
> the opposite of what I've proposed? |
149 |
> |
150 |
> If LINGUAS is marked as advanced variable you're not supposed to use, |
151 |
> I don't care about its side effects. I care about L10N and files |
152 |
> stripped via INSTALL_MASKs. If you use LINGUAS, you're on your own. |
153 |
|
154 |
Then why do you claim that l10n.eclass (which then of course must |
155 |
be updated to treat IUSE=l10n_* in the way it does currently with |
156 |
instead of IUSE=linguas_*) should be removed? |
157 |
l10n.eclass together with |
158 |
export LINGUAS=$L10N |
159 |
should be exactly the right behaviour for all packages currently |
160 |
supporting IUSE=linguas_*. Why should this perfectly working thing |
161 |
(at least for those ebuilds which support it) now be removed? |
162 |
What would be the benefit for the user? I see only the disadvantage |
163 |
that some users now have to do the job of the package manager even |
164 |
for these packages... |