1 |
On pią, 2017-08-11 at 19:50 -0400, Michael Orlitzky wrote: |
2 |
> We have a pull request for the devmanual that will update the revision |
3 |
> documentation; namely, when to create a new one: |
4 |
> |
5 |
> https://github.com/gentoo/devmanual.gentoo.org/pull/67 |
6 |
> |
7 |
> The comments bring up an issue that I think can benefit from some |
8 |
> hindsight. Specifically, the PR says that it's OK to change IUSE without |
9 |
> creating a revision, because users can use --changed-use to catch it. |
10 |
> My immediate objection to that was that --changed-use is specific to |
11 |
> Portage, but let's reflect on the status quo. |
12 |
> |
13 |
> |
14 |
> == The situation now == |
15 |
> |
16 |
> 1 We tell everyone to update with either --newuse or --changed-use. |
17 |
> |
18 |
> 2 Developers change IUSE without new revisions. |
19 |
> |
20 |
> 3 To facilitate (1) and (2), Portage has the --changed-use and |
21 |
> --newuse flags. Paludis has a family of "--keep" options to avoid |
22 |
> reinstallation, e.g. --keep=if-same-metadata. And pkgcore has its |
23 |
> own (different) --newuse flag. |
24 |
> |
25 |
> 4 There is no specification for the features in (3), and each package |
26 |
> manager has taken a different approach. |
27 |
> |
28 |
> |
29 |
> The end result is that Portage users do see the changes made to IUSE |
30 |
> without a revision, but at a cost: |
31 |
> |
32 |
> * They have to pass the "required" --changed-use or --newuse flags to |
33 |
> every command. |
34 |
> |
35 |
> * The same cannot be said for users of other package managers. |
36 |
> |
37 |
> * Lots of PM code exists to handle this stuff. |
38 |
> |
39 |
> * Our documentation needs to describe the above (relatively) |
40 |
> complicated situation. |
41 |
> |
42 |
> |
43 |
> And with one notable benefit: |
44 |
> |
45 |
> * We don't need to rename the ebuild to change IUSE, and in theory we |
46 |
> can control when rebuilds happen. |
47 |
> |
48 |
> |
49 |
> |
50 |
> == New revisions for USE flag changes == |
51 |
> |
52 |
> I suggest that in hindsight, we can do better. Suppose we require a new |
53 |
> revision for every change to IUSE. Then, |
54 |
> |
55 |
> * We can delete all of the PM code for --changed-use and --newuse and |
56 |
> friends. |
57 |
> |
58 |
> * The documentation becomes much simpler: revbump if IUSE changes. |
59 |
> |
60 |
> * Users can omit --newuse and --changed-use from their lives. |
61 |
> |
62 |
> * All package managers now handle IUSE changes properly. |
63 |
> |
64 |
> * emerge runs a bit faster. |
65 |
> |
66 |
> This has none of the downsides of the current approach. Of course, it |
67 |
> lacks that one benefit -- that you don't have to rename the ebuild when |
68 |
> you change IUSE. Now I'll try to convince you that the rename and |
69 |
> associated rebuilds aren't that big of a deal. |
70 |
> |
71 |
> |
72 |
> Q. But what about the rebuilds? |
73 |
> |
74 |
> For most packages, the rebuilds simply don't matter. Unless you're |
75 |
> the maintainer of libreoffice, firefox, chromium, etc. -- just do the |
76 |
> revision and forget about the (quick) rebuilds. |
77 |
> |
78 |
> We tell everyone to use --changed-use and --newuse if they want |
79 |
> things to work, so they were probably going to rebuild anyway. |
80 |
> |
81 |
> |
82 |
> Q. But what if I maintain firefox, and I need to change IUSE? |
83 |
> |
84 |
> If the IUSE change isn't important, just make the new revision in a |
85 |
> branch and wait to commit it later when there are more changes |
86 |
> piled up. If it is important (like if its default value changes |
87 |
> RDEPEND), then it would have required a revision anyway. |
88 |
> |
89 |
> |
90 |
> Q. But I work on a team, and we can't all work in different branches. |
91 |
> |
92 |
> If you work on a massive package and if you're collaborating with |
93 |
> others regularly, you can commit the new ebuild masked. This is |
94 |
> annoying, but is an extremely rare combination of circumstances. |
95 |
> |
96 |
> |
97 |
> == tl;dr == |
98 |
> |
99 |
> We would be better off with respect to IUSE changes and revisions if we |
100 |
> deleted the --changed-use and --newuse flags right now, and just |
101 |
> required developers to revbump when changing IUSE. |
102 |
> |
103 |
> Package managers get simpler, documentation gets simpler, the user |
104 |
> interface gets simpler, and behavior becomes more uniform and predictable. |
105 |
> |
106 |
> Please let me know what you think. |
107 |
> |
108 |
|
109 |
Please provide some examples of recent in-place USE changes that benefit |
110 |
from revbumps. |
111 |
|
112 |
-- |
113 |
Best regards, |
114 |
Michał Górny |