1 |
Dnia 2013-11-13, o godz. 10:28:02 |
2 |
Martin Vaeth <vaeth@××××××××××××××××××××××××.de> napisał(a): |
3 |
|
4 |
> As I understand, it tries to solve a "social" issue |
5 |
> (that an ARCH user might set a USE-flag which eventually |
6 |
> pulls in an ~ARCH package) on a technical level |
7 |
> (by forcibly disabling the USE-flag for the user). |
8 |
> Solving social problems by technical means is never a good |
9 |
> idea: |
10 |
|
11 |
Then you don't understand it. |
12 |
|
13 |
The basic issue is that we couldn't stabilize a package without |
14 |
stabilizing all of its optional dependencies. For example, consider |
15 |
Python 3.3. In order to get proper testing of it on testing, we had to |
16 |
enable support for it in packages. But when we introduced that support, |
17 |
the package immediately gained a dep on python:3.3. |
18 |
|
19 |
If the package was supposed to go stable, we would either have to |
20 |
stabilize Python 3.3 (too early for that), wait for Python 3.3 |
21 |
(resulting in very long to infinite) or drop Python 3.3 support. There |
22 |
were even cases when I had to revbump a package in order to keep |
23 |
'limited' revision to stabilize and 'full' to keep testing. |
24 |
|
25 |
Just to be clear -- this isn't only a social issue. This is a valid QA |
26 |
concern that we had no distinction between 'flags that are fine on |
27 |
stable' and 'flags that are not'. If some flags work and some do not, |
28 |
resulting in 'unsatisfiable dep' errors, this is technical. |
29 |
|
30 |
> While the former gives the stable user a clear message |
31 |
> what is going wrong (after all, many stable users want |
32 |
> some package which has not a stable version yet, so this |
33 |
> should be something everybody should be able to handle), |
34 |
> the latter hides causes and makes things almost unpredictable: |
35 |
|
36 |
Answer yourself the following questions: does portage suggest removing |
37 |
the flag in the case? Does portage in any way explain that a particular |
38 |
dependency was pulled in due to USE flag? |
39 |
|
40 |
It's easy to use words like 'clear message' when you want to prove your |
41 |
point. And I have no idea what you mean by 'something everybody should |
42 |
be able to handle', unless you assume that the main purpose of a stable |
43 |
system is to turn it into mixed-keyword system. |
44 |
|
45 |
And just in case: the proper course of action then is to *report |
46 |
a bug*. And in the end, thanks to your glorified solution, we end up |
47 |
with dozens or hundreds of 'CANTFIX' bugs. |
48 |
|
49 |
> Even if the user has put the dependency into |
50 |
> package.accept_keywords, he will not be able to use the |
51 |
> USE-flag on his packages unless |
52 |
> *he puts stable versions into package.accept_keywords* |
53 |
> (or - simlarly worse - overrides the profile). |
54 |
|
55 |
If you have a problem with USE flag being masked, you unmask the USE |
56 |
flag. It is simple like this. |
57 |
|
58 |
I don't agree with the whole idea of unmasking flags via playing with |
59 |
accept_keywords. In my opinion, it's just a terrible bug or mis-design. |
60 |
It's not something that should be encouraged, or even happen. |
61 |
|
62 |
If you unmask testing package just to get testing keywords, you quickly |
63 |
lose the point of having stable keywords. Putting just the stable |
64 |
versions is a pointless nightmare. |
65 |
|
66 |
Even worse than that, people with mixed systems get extra flags even if |
67 |
they don't want them. And this is an easy way to have them end up with |
68 |
half of the system on testing. |
69 |
|
70 |
> The really bad thing is that this is happening by magic |
71 |
> "behind the user's back", i.e. contradicting the user's setting |
72 |
> of USE-flag and package.use: If the user does not carefully |
73 |
> read emerge's -v output, he even does not get informed that |
74 |
> the support for his unstable package is dropped from the |
75 |
> stable package, despite he might have specified the corresponding |
76 |
> USE-flag globally. Even worse, even when reading the output |
77 |
> carefully, the user cannot understand the reason: |
78 |
> Since there are many reasons why use-flags can appear in () |
79 |
> he will probably not even conjecture that actually something |
80 |
> will not be working as he expected. |
81 |
|
82 |
It's magic only because you did it wrong. |
83 |
|
84 |
> Here are some other examples of negative effects happening |
85 |
> just recently to me, ordered from not so severe to very bad: |
86 |
> |
87 |
> 1. For several reasons I always want the most current |
88 |
> emul-linux-x86* libraries, so they are in package.accept_keywords. |
89 |
> Due to global ABI_X86=32 (which I also want), this forced me |
90 |
> of course to put several libraries to ~amd64 since only |
91 |
> new version support this. Some of the libraries are actually |
92 |
> stable, so I have removed them from package.accept_keywords. |
93 |
> So far, so good. |
94 |
> But suddenly portage spitted unexplainable dependency errors, |
95 |
> and I only expert users manually reading the profiles can |
96 |
> understand that the reason is that use.stable.mask requires |
97 |
> that stable versions need to be keyworded ~amd64 |
98 |
> (or use.stable.mask has to be overridden in my profile). |
99 |
|
100 |
Which wouldn't happen if package.accept_keywords didn't implicitly |
101 |
unmask flags. |
102 |
|
103 |
> 2. Just a few days ago dev-lang/python-exec:2 became stable |
104 |
> on amd64, but dev-python/python-exec:2 is still ~amd64. |
105 |
|
106 |
And this was a bug that would have been fixed if you cared reporting it |
107 |
straight to us rather than kept is as an argument. |
108 |
|
109 |
> 3. As a side effect of 2., I realized that libreoffice and a dozen |
110 |
> further packages get forced a rebuild. So, if eventually |
111 |
> python-3.3 becomes stable and is removed from use.stable.mask, |
112 |
> all stable users will have to rebuild almost their whole world, |
113 |
> because python-exec then has one more "dummy" USE-flag. The same |
114 |
> will happen again if pypy-2.0 becomes stable. |
115 |
> So a lot of unnecessary rebuilds happen to stable users because |
116 |
> of {package.,}use.stable.mask which most of the developers |
117 |
> (who are often ~amd64 users) do not realize. |
118 |
|
119 |
I don't get this. A masked flag is equivalent to a disabled flag. What |
120 |
would cause the rebuild then? |
121 |
|
122 |
-- |
123 |
Best regards, |
124 |
Michał Górny |