1 |
On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) |
2 |
Martin Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
3 |
|
4 |
> Hello. |
5 |
> |
6 |
> The new "features" use.stable.mask and package.use.stable.mask |
7 |
> have turned maintaining systems with mixed ARCH and ~ARCH keywords |
8 |
> into a nightmare: |
9 |
|
10 |
They are considered unsupported by many; so, going down that path you |
11 |
need to be acquainted with Portage enough to keep a consistent system. |
12 |
|
13 |
> Similarly to the (fortunately dropped) concept of forcing |
14 |
> useflags if certain packages are installed this forces a |
15 |
> magic on the user which can hardly be managed since it is |
16 |
> not clearly presented to the user but hidden in some profiles. |
17 |
> |
18 |
> As I understand, it tries to solve a "social" issue |
19 |
> (that an ARCH user might set a USE-flag which eventually |
20 |
> pulls in an ~ARCH package) on a technical level |
21 |
> (by forcibly disabling the USE-flag for the user). |
22 |
|
23 |
That's one approach, it might also be used when a package can be |
24 |
stabilized but a certain of feature of the package cannot; eg. |
25 |
USE="minimal" could be broken on a certain package because it removed a |
26 |
bit too much, thus it could be stabilized with USE="-minimal" forced. |
27 |
|
28 |
Anyhow, I think we should make sure to weight "why we need to have it" |
29 |
against "how it bothers which users"; and not just focus on users alone. |
30 |
|
31 |
And other than that, are there alternatives? Something we can do better? |
32 |
|
33 |
Sometimes problems can be resolved by better communication too; perhaps |
34 |
there are things we can inform the user about in pkg_postinst, or |
35 |
improve Portage to let the user know of a particular forced USE flag. |
36 |
|
37 |
> Solving social problems by technical means is never a good |
38 |
> idea: |
39 |
> |
40 |
> While the former gives the stable user a clear message |
41 |
> what is going wrong (after all, many stable users want |
42 |
> some package which has not a stable version yet, so this |
43 |
> should be something everybody should be able to handle), |
44 |
> the latter hides causes and makes things almost unpredictable: |
45 |
> |
46 |
> Even if the user has put the dependency into |
47 |
> package.accept_keywords, he will not be able to use the |
48 |
> USE-flag on his packages unless |
49 |
> *he puts stable versions into package.accept_keywords* |
50 |
> (or - simlarly worse - overrides the profile). |
51 |
|
52 |
That are indeed the two approaches, I don't see a problem with putting |
53 |
the version itself in accept_keywords or overriding the profile; |
54 |
furthermore, overriding forced and/or masked USE flag is the exception, |
55 |
it doesn't happen so frequently so I doubt this is a huge problem. |
56 |
|
57 |
> The really bad thing is that this is happening by magic |
58 |
> "behind the user's back", i.e. contradicting the user's setting |
59 |
> of USE-flag and package.use: If the user does not carefully |
60 |
> read emerge's -v output, he even does not get informed that |
61 |
> the support for his unstable package is dropped from the |
62 |
> stable package, despite he might have specified the corresponding |
63 |
> USE-flag globally. |
64 |
|
65 |
System upgrades have to be done carefully; so, the user skipping it is |
66 |
something we cannot account for except perhaps providing support for |
67 |
the user receiving some kind of verbose summary of such forces / masks |
68 |
being present at the end of the emerge output. But you'll have to |
69 |
contact the Portage developers to achieve such improvements. |
70 |
|
71 |
> Even worse, even when reading the output |
72 |
> carefully, the user cannot understand the reason: |
73 |
> Since there are many reasons why use-flags can appear in () |
74 |
> he will probably not even conjecture that actually something |
75 |
> will not be working as he expected. |
76 |
|
77 |
Most of these reasons can be uniquely determined from the output; but |
78 |
indeed, some might yield the same output, but this is again something |
79 |
that the Portage developers can improve and not a reason for removal. |
80 |
|
81 |
> Here are some other examples of negative effects happening |
82 |
> just recently to me, ordered from not so severe to very bad: |
83 |
> |
84 |
> 1. For several reasons I always want the most current |
85 |
> emul-linux-x86* libraries, so they are in package.accept_keywords. |
86 |
> Due to global ABI_X86=32 (which I also want), this forced me |
87 |
> of course to put several libraries to ~amd64 since only |
88 |
> new version support this. Some of the libraries are actually |
89 |
> stable, so I have removed them from package.accept_keywords. |
90 |
> So far, so good. |
91 |
> But suddenly portage spitted unexplainable dependency errors, |
92 |
> and I only expert users manually reading the profiles can |
93 |
> understand that the reason is that use.stable.mask requires |
94 |
> that stable versions need to be keyworded ~amd64 |
95 |
> (or use.stable.mask has to be overridden in my profile). |
96 |
|
97 |
This confuses me; isn't the goal to have one multilib apprach or the |
98 |
other? Especially due to the blockers between them. |
99 |
|
100 |
I agree Portage output can be better, I'm not sure if use.stable.mask |
101 |
is really the problem here though; but rather the nature of mixing them. |
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 |
> Just to be sure to not miss anything, I have put the latter |
106 |
> into package.accept_keywords, and hell break loose: |
107 |
|
108 |
Hell indeed breaks loose if you mix stable and unstable; but note that |
109 |
this package had an accident, see the related news item for details. |
110 |
|
111 |
> Portaqe wanted me to emerge the git version of |
112 |
> dev-lang/python-exec:0 and reemerge dozens of packages. |
113 |
|
114 |
This is a consequence of that hell; if you don't agree and this is due |
115 |
to the Portage tree, please show the dependency chain that causes this. |
116 |
|
117 |
> I needed hours to find out what is the actual cause: |
118 |
> The package.accept_keywords caused the use.stable.mask of |
119 |
> python_targets_pypy2_0 und python_targets_python3_3 to become |
120 |
> ineffective for dev-python/python-exec, |
121 |
|
122 |
It doesn't matter, dev-python/python-exec installs no contents. |
123 |
|
124 |
> but of course it is still |
125 |
> effective for dev-lang/python-exec which is not be the case |
126 |
> if I unmask the git version of dev-lang/python-exec. |
127 |
|
128 |
Which one is not meant to do anyway; and from what you wrote, I don't |
129 |
think you intent to either. |
130 |
|
131 |
> This is completely confusing since nowhere the git-version |
132 |
> is marked differently than the non-git version. |
133 |
|
134 |
Marked in which way? One is stable, the other unkeyworded. |
135 |
|
136 |
> So, yes, portage's behaviour can be explained, but, no, |
137 |
> it is not understandable by a user who wants portage |
138 |
> to report what is really wrong and who does not want |
139 |
> to check manually by reading all profiles and hunt down |
140 |
> for reasons why certain flags are magically forced/disabled. |
141 |
|
142 |
Which output are we discussing here? |
143 |
|
144 |
If it is due to the hell above, we warn users up front for that. |
145 |
|
146 |
> 3. As a side effect of 2., I realized that libreoffice and a dozen |
147 |
> further packages get forced a rebuild. So, if eventually |
148 |
> python-3.3 becomes stable and is removed from use.stable.mask, |
149 |
> all stable users will have to rebuild almost their whole world, |
150 |
> because python-exec then has one more "dummy" USE-flag. The same |
151 |
> will happen again if pypy-2.0 becomes stable. |
152 |
> So a lot of unnecessary rebuilds happen to stable users because |
153 |
> of {package.,}use.stable.mask which most of the developers |
154 |
> (who are often ~amd64 users) do not realize. |
155 |
|
156 |
That is to be expected on such stabilizations, I doubt they are |
157 |
unnecessary; if I misunderstood, feel free to give an example. |
158 |
|
159 |
-- |
160 |
With kind regards, |
161 |
|
162 |
Tom Wijsman (TomWij) |
163 |
Gentoo Developer |
164 |
|
165 |
E-mail address : TomWij@g.o |
166 |
GPG Public Key : 6D34E57D |
167 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |