1 |
On 01/28/2014 02:34 AM, Martin Vaeth wrote: |
2 |
> hasufell <hasufell@g.o> wrote: |
3 |
>> |
4 |
>> On 01/27/2014 12:26 AM, William Hubbs wrote: |
5 |
>>> |
6 |
>>> No, starting with USE="-*" is very dangerous. |
7 |
>> |
8 |
>> That's nonsense imo |
9 |
> |
10 |
> No, William is completely right. |
11 |
> |
12 |
>> and I use that setup on multiple servers/routers without any issues. |
13 |
> |
14 |
> No one doubts that it is *possible* to add the correct USE for |
15 |
> every single package manually, but it is not a good idea to hide |
16 |
> the recommended defaults. |
17 |
> |
18 |
|
19 |
As someone who writes those recommendations, I disagree. That's why many |
20 |
of my packages don't have a lot of them, because I don't like them in |
21 |
the first place. Another nice thing you can do is mess with USE_ORDER. |
22 |
And now don't tell me that is another bad idea. This is Gentoo. |
23 |
|
24 |
>> It makes sense because you have the most minimal setup possible |
25 |
> |
26 |
> This is not true, to start with: For instance, USE=minimal will |
27 |
> usually choose a more minimal setup. |
28 |
> With "-*" you will actually *disable* the default USE=minimal |
29 |
> for e.g. www-client/firefox, x11-apps/startx, sys-block/blocks, |
30 |
> dev-db/unixODBC, ... and thus get a setup which is even larger |
31 |
> than the recommended default. |
32 |
> |
33 |
|
34 |
USE="-* minimal" |
35 |
|
36 |
>> most minimal codepaths possible which reduces exposure to bugs. |
37 |
> |
38 |
> No, you usually get less tested (and by upstream considered untypical) |
39 |
> codepaths which actually increases the probability to hit a bug |
40 |
> nobody did hit/test yet. |
41 |
> |
42 |
|
43 |
Many defaults gentoo sets do not have anything to do with default |
44 |
codepaths upstream has tested. So this argument works both ways. |
45 |
Especially after a profile is activated. |
46 |
|
47 |
> The USE="-*" approach was reasonable before EAPI=1 was introduced: |
48 |
> In these days, unusual codepaths would have been set by "negative" |
49 |
> USE-flags, e.g. IUSE="nocxx" for gcc. |
50 |
> Nowadays, the upstream-recommended codepaths are set by default-USE-Flags |
51 |
> in the ebuild, i.e. now the same is called IUSE="+cxx" in gcc. |
52 |
> Using -* you disable such defaults which are usually there for a |
53 |
> good reason. |
54 |
|
55 |
As above, our defaults are not necessarily following upstream |
56 |
recommendations/defaults. Apache alone should make you think about that |
57 |
claim. |
58 |
|
59 |
> |
60 |
> Of course, if you know and care what every single USE-flags for every |
61 |
> single package does, it does not matter much which approach you take, |
62 |
> but I would guess that even in this case you need more exceptions |
63 |
> in /etc/portage/package.use with USE="-*" than with USE="". |
64 |
> |
65 |
|
66 |
I made the opposite experience. |
67 |
|
68 |
> Moreover, even for updates, it happens occassionally that a package |
69 |
> gets an additional USE-flag, whose default is then usually chosen in |
70 |
> such a way as the behaviour was before - so you risk dropping |
71 |
> crucial behaviour on updates if you are not very careful. |
72 |
> |
73 |
|
74 |
I am careful. The amount of crucial packages on my servers are not that |
75 |
big and I definitely watch _any_ update, unless I want a mysql update to |
76 |
break hell. |
77 |
|
78 |
|
79 |
Besides, if a useflag combination breaks something unexpectedly (e.g. |
80 |
the build or unrelated features) then it's a bug (minimum is to |
81 |
communicate the situation via elog). If disabling one useflag breaks the |
82 |
whole package, then it's a bug. That's something the packager has to |
83 |
care about and arch testers usually run all(or most?) useflag |
84 |
permutations before stabilizing. |
85 |
There is no excuse. Every other "breakage" is expected, because I have |
86 |
disabled the features. |
87 |
The power of useflags imply that I can mix them up any way I want. All |
88 |
of those mixtures must be supported by the maintainer, unless he warns |
89 |
the user about it through the ebuild, masks the useflag or sets an |
90 |
appropriate REQUIRED_USE constraint. Otherwise... it's a bug. |