1 |
Michał Górny <mgorny@g.o> wrote: |
2 |
> |
3 |
>> As I understand, it tries to solve a "social" issue |
4 |
>> (that an ARCH user might set a USE-flag which eventually |
5 |
>> pulls in an ~ARCH package) on a technical level |
6 |
>> (by forcibly disabling the USE-flag for the user). |
7 |
>> Solving social problems by technical means is never a good |
8 |
>> idea: |
9 |
> |
10 |
> Then you don't understand it. |
11 |
> |
12 |
> The basic issue is that we couldn't stabilize a package without |
13 |
> stabilizing all of its optional dependencies. |
14 |
|
15 |
Exactly: The social issue is that you have this rule fixed |
16 |
without any exceptions and do not want to discuss about exceptions. |
17 |
|
18 |
> There were even cases when I had to revbump a package in order to keep |
19 |
> 'limited' revision to stabilize and 'full' to keep testing. |
20 |
|
21 |
The social issue has to be solved and it has to be clarified |
22 |
when packages are allowed to have USE-flags depending on unstable |
23 |
packages which the user has to resolve when he wants them. |
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 |
No. The user has to be told that he *should* not use such certain |
31 |
flags on a stable system. This can happen by portage reporting |
32 |
a message that some USE-dependency is pulling in an unstable package, |
33 |
but it can also happen in a different way. |
34 |
The use.stable.mask "solution" is to not inform the user but just |
35 |
decide behind his back that he cannot use the flag and enforce |
36 |
this decision. |
37 |
Instead, e.g. one can let portage report if some useflag described |
38 |
in use.stable.mask needs to be disabled, or one can use some |
39 |
"I_KNOW_WHAT_I_AM_DOING" name, or whatever. There are many ways |
40 |
of reporting. But forcing a decision on the user without even |
41 |
communicating reasonably why this decision was forced is very bad IMHO. |
42 |
|
43 |
> Answer yourself the following questions: does portage suggest removing |
44 |
> the flag in the case? Does portage in any way explain that a particular |
45 |
> dependency was pulled in due to USE flag? |
46 |
|
47 |
The output can easily be improved: It is not rocket |
48 |
science to list "required by category/package[FLAG]" instead of |
49 |
"required by category/package" or to display the relevant part |
50 |
of the dependency string (something similar is done already for |
51 |
REQUIRED_USE, so the logic probably already exists in portage). |
52 |
|
53 |
> And just in case: the proper course of action then is to *report |
54 |
> a bug*. And in the end, thanks to your glorified solution, we end up |
55 |
> with dozens or hundreds of 'CANTFIX' bugs. |
56 |
|
57 |
Yeah, it is much better to throw the users into dependency hell |
58 |
in which they have no clue how to find out. Certainly they will |
59 |
never report any bugs in this case when they can so easily solve |
60 |
this by just going through all dependencies and all profiles |
61 |
manually and understanding all details. |
62 |
|
63 |
> If you have a problem with USE flag being masked, you unmask the USE |
64 |
> flag. It is simple like this. |
65 |
|
66 |
Yes, the sane way to deal with use.stable.mask for the user is to |
67 |
undo manually everything which is set there. |
68 |
But is it really a good feature, if the user essentially only |
69 |
removes it? |
70 |
|
71 |
> I don't agree with the whole idea of unmasking flags via playing with |
72 |
> accept_keywords. In my opinion, it's just a terrible bug or mis-design. |
73 |
> It's not something that should be encouraged, or even happen. |
74 |
|
75 |
I completely agree. |
76 |
But the only way to unmask it otherwise is to undo use.stable.mask. |
77 |
Then why have use.stable.mask in the first place? |
78 |
Moreover, for use.stable.mask this cannot happen on a per-package basis. |
79 |
|
80 |
Perhaps one can introduce a better way to unmask use.stable.mask? |
81 |
|
82 |
> Even worse than that, people with mixed systems get extra flags even if |
83 |
> they don't want them. And this is an easy way to have them end up with |
84 |
> half of the system on testing. |
85 |
|
86 |
Do you mean by "extra flags" again those of use.package.mask? |
87 |
Then isn't this again an argument against use.package.mask at all? |
88 |
|
89 |
> It's magic only because you did it wrong. |
90 |
|
91 |
No, it is magic because it makes a decision (pulling in ~amd64 |
92 |
or unsetting USE) without communicating appropriately with the user |
93 |
and even without giving him a clean possibility to decide differently. |
94 |
(Modifying the profile is more a hack than a clean possibility). |
95 |
|
96 |
Moreover, once the thing is removed from use.stable.mask he gets |
97 |
tricked a second time by suddenly a useflag popping up. |
98 |
(OK, this time, he *does* get informed and has a clean possibility |
99 |
to change, so this time his surprise is limited). |
100 |
|
101 |
> Which wouldn't happen if package.accept_keywords didn't implicitly |
102 |
> unmask flags. |
103 |
|
104 |
Exactly. This is why it becomes a dependency hell. |
105 |
But wouldn't removing this go against the purpose of use.stable.mask? |
106 |
|
107 |
> I don't get this. A masked flag is equivalent to a disabled flag. What |
108 |
> would cause the rebuild then? |
109 |
|
110 |
All python versions are use.force'd in this package. |
111 |
However, those which are use.stable.mask'ed are not use.force'd, |
112 |
because use.stable.mask overrides use.force (which makes sense). |
113 |
So if the use.stable.mask entry changes, the active USE-flags |
114 |
in the package change automatically, and the user cannot do anything |
115 |
against it (except modifying the profile). |