1 |
On 08/12/2017 09:50 AM, Michael Orlitzky wrote: |
2 |
> Q. But what about the rebuilds? |
3 |
> |
4 |
> For most packages, the rebuilds simply don't matter. Unless you're |
5 |
> the maintainer of libreoffice, firefox, chromium, etc. -- just do the |
6 |
> revision and forget about the (quick) rebuilds. |
7 |
|
8 |
I really wish people would stop trotting out this false argument. Not |
9 |
everyone has the latest and greatest hardware. Rebuilds have a real cost |
10 |
to end users and as such we should use them wisely. |
11 |
|
12 |
> We tell everyone to use --changed-use and --newuse if they want |
13 |
> things to work, so they were probably going to rebuild anyway. |
14 |
|
15 |
Who tells everyone to use these flags and where? I never use these flags |
16 |
day-to-day, only if I need that specific functionality for that reason |
17 |
|
18 |
> Q. But what if I maintain firefox, and I need to change IUSE? |
19 |
> |
20 |
> If the IUSE change isn't important, just make the new revision in a |
21 |
> branch and wait to commit it later when there are more changes |
22 |
> piled up. If it is important (like if its default value changes |
23 |
> RDEPEND), then it would have required a revision anyway. |
24 |
|
25 |
Please stop trying to force workflows on people. Using that same logic, |
26 |
I can make the IUSE change in-place and it would be propagated in the |
27 |
next version bump. |
28 |
|
29 |
> Q. But I work on a team, and we can't all work in different branches. |
30 |
> |
31 |
> If you work on a massive package and if you're collaborating with |
32 |
> others regularly, you can commit the new ebuild masked. This is |
33 |
> annoying, but is an extremely rare combination of circumstances. |
34 |
|
35 |
Again, let's not try and tell teams which workflow works best for them. |
36 |
|
37 |
> == tl;dr == |
38 |
> |
39 |
> We would be better off with respect to IUSE changes and revisions if we |
40 |
> deleted the --changed-use and --newuse flags right now, and just |
41 |
> required developers to revbump when changing IUSE. |
42 |
> |
43 |
> Package managers get simpler, documentation gets simpler, the user |
44 |
> interface gets simpler, and behavior becomes more uniform and predictable. |
45 |
> |
46 |
> Please let me know what you think. |
47 |
|
48 |
I disagree with this change because your proposed benefits don't hold up: |
49 |
|
50 |
> * We can delete all of the PM code for --changed-use and --newuse and |
51 |
> friends. |
52 |
|
53 |
As pointed out by Brian, we still need at least --changed-use even if |
54 |
IUSE changes in-place are banned. |
55 |
|
56 |
> * The documentation becomes much simpler: revbump if IUSE changes. |
57 |
|
58 |
We should base our policies around the cost / benefit of said policy, |
59 |
not how many or few words we need to write in the devmanual about it. |
60 |
|
61 |
> * Users can omit --newuse and --changed-use from their lives. |
62 |
|
63 |
They already can. |
64 |
|
65 |
> * All package managers now handle IUSE changes properly. |
66 |
|
67 |
If you want to see consistent behaviour in how package manages handle |
68 |
IUSE, I suggest sending patches for PMS. I don't see any problem in |
69 |
portage/paludis/pkgcore handling things differently. That is the point |
70 |
of having different package managers, after all. |
71 |
|
72 |
> * emerge runs a bit faster. |
73 |
|
74 |
Why will it run faster? |