1 |
On 01/28/2018 10:47 AM, Alec Warner wrote: |
2 |
> |
3 |
> |
4 |
> On Sun, Jan 28, 2018 at 1:09 PM, Zac Medico <zmedico@g.o |
5 |
> <mailto:zmedico@g.o>> wrote: |
6 |
> |
7 |
> On 01/28/2018 09:35 AM, Alec Warner wrote: |
8 |
> > |
9 |
> > |
10 |
> > On Sun, Jan 28, 2018 at 9:51 AM, Zac Medico <zmedico@g.o <mailto:zmedico@g.o> |
11 |
> > <mailto:zmedico@g.o <mailto:zmedico@g.o>>> wrote: |
12 |
> > |
13 |
> > The --dynamic-deps=n default causes confusion for users that are |
14 |
> > accustomed to dynamic deps, therefore add a --changed-deps-report |
15 |
> > option that is enabled by default (if --usepkgonly is not |
16 |
> enabled). |
17 |
> > |
18 |
> > The --quiet option will suppress the report if none of the |
19 |
> packages |
20 |
> > having changed dependencies are in the dependency graph, since |
21 |
> they |
22 |
> > are harmless in that case. If any of these packages *are* in the |
23 |
> > dependency graph, then --quiet suppresses the big NOTE section of |
24 |
> > the report, but the HINT section is still displayed since it might |
25 |
> > help users resolve problems that are solved by --changed-deps. |
26 |
> > |
27 |
> > Example output is as follows: |
28 |
> > |
29 |
> > !!! Detected ebuild dependency change(s) without revision bump: |
30 |
> > |
31 |
> > net-misc/openssh-7.5_p1-r3::gentoo |
32 |
> > sys-fs/udisks-2.7.5::gentoo |
33 |
> > |
34 |
> > NOTE: For the ebuild(s) listed above, a new revision may be |
35 |
> > warranted if there |
36 |
> > has been a dependency change with significant consequences. |
37 |
> > Refer to the |
38 |
> > following page of the Gentoo Development Guide for |
39 |
> examples of |
40 |
> > circumstances that may qualify: |
41 |
> |
42 |
> > |
43 |
> > |
44 |
> > |
45 |
> https://devmanual.gentoo.org/general-concepts/ebuild-revisions/ |
46 |
> <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/> |
47 |
> > |
48 |
> <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/ |
49 |
> <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/>> |
50 |
> |
51 |
> > |
52 |
> > If circumstances qualify, please report a bug which |
53 |
> specifies |
54 |
> > the current |
55 |
> > version of the ebuild listed above. Changes to ebuilds from |
56 |
> > the 'gentoo' |
57 |
> > repository (ending with '::gentoo') can be browsed in |
58 |
> GitWeb: |
59 |
> > |
60 |
> > https://gitweb.gentoo.org/repo/gentoo.git/ |
61 |
> <https://gitweb.gentoo.org/repo/gentoo.git/> |
62 |
> > <https://gitweb.gentoo.org/repo/gentoo.git/ |
63 |
> <https://gitweb.gentoo.org/repo/gentoo.git/>> |
64 |
> > |
65 |
> > Use Gentoo's Bugzilla to report bugs only for the 'gentoo' |
66 |
> > repository: |
67 |
> > |
68 |
> > https://bugs.gentoo.org/ |
69 |
> > |
70 |
> > In order to suppress reports about dependency changes, add |
71 |
> > --changed-deps-report=n to the EMERGE_DEFAULT_OPTS |
72 |
> variable in |
73 |
> > '/etc/portage/make.conf'. |
74 |
> > |
75 |
> > HINT: In order to avoid problems involving changed |
76 |
> dependencies, use the |
77 |
> > --changed-deps option to automatically trigger rebuilds when |
78 |
> > changed |
79 |
> > dependencies are detected. Refer to the emerge man page |
80 |
> for more |
81 |
> > information about this option. |
82 |
> > |
83 |
> > Bug: https://bugs.gentoo.org/645780 |
84 |
> > |
85 |
> > |
86 |
> > I can't really support sending this large report to users. |
87 |
> > |
88 |
> > 1) Its fairly common practice today. |
89 |
> > 2) All users will get the report. |
90 |
> > 3) A subset of them will file bugs about the report. |
91 |
> > 4) Devs make a decision about revbumping vs not; there doesn't seem to |
92 |
> > be a way for devs to say "no this change is intentional, stop nagging |
93 |
> > users." |
94 |
> |
95 |
> I think in practice we need to revbump for most changes. If the changes |
96 |
> weren't worth propagating, then we wouldn't make them. |
97 |
> |
98 |
> > Ultimately I'm unsure what we are trying to accomplish here. Do we think |
99 |
> > Devs are doing 4 on accident? |
100 |
> |
101 |
> It doesn't matter whether it's intentional or an accident. The problem |
102 |
> is that users need to learn to react appropriately, and I think |
103 |
> --change-deps-report is probably the most efficient way to train them. |
104 |
> |
105 |
> |
106 |
> I guess I'm less convinced users can / should do it. |
107 |
> |
108 |
> Like they have to read the ebuild-revisions guide in the devmanual and |
109 |
> decide if the revbump is required or not? |
110 |
> Do we think users are able to do this? |
111 |
|
112 |
Maybe some. The worst case is that they file a bug and the developer |
113 |
gets to see a useful message in the bug report. |
114 |
|
115 |
I don't expect this case to be the norm, because I expect that |
116 |
developers usually do the right thing given the necessary reinforcement. |
117 |
|
118 |
> Should we consider only showing reports to developers (e.g. putting it |
119 |
> behind a 'dev' FEATURE?) |
120 |
|
121 |
What are the users supposed to do if they have dependency calculation |
122 |
failure and they don't know about the --changed-deps option? Why not |
123 |
instantly notified them that the --changed-deps option is available to |
124 |
solve their problems? |
125 |
|
126 |
Again, I don't expect this case to be the norm. It's a safety net. |
127 |
|
128 |
> > If so, why can't we give them tools to find it ahead of time (repoman |
129 |
> > et. al.) or tools to find it post-commit (tinderbox or similar; but |
130 |
> > these are single-sourced reports.) |
131 |
> |
132 |
> Sure that can be done, but it will take some work. Honestly I think the |
133 |
> devs can get it right without all that, they just need some |
134 |
> reinforcement that has been absent up until now. |
135 |
> |
136 |
> Meanwhile, users need to be trained to cope with whatever comes |
137 |
> their way. |
138 |
> |
139 |
> > I also feel like we are pushing action onto users here. If we agree with |
140 |
> > the premise that this is a bug (and devs should always bump) then we |
141 |
> > don't need users to take any action; |
142 |
> |
143 |
> I really do think that the devs can learn to get it right with a little |
144 |
> reinforcement. |
145 |
> |
146 |
> > we could build automation that sends these 'reports'. Its not like the |
147 |
> > user is going to add anything interesting to the report. Making them do |
148 |
> > it by hand just introduces transcription errors in filing. We just need |
149 |
> > to get their permission to file the reports automatically when portage |
150 |
> > finds them. |
151 |
> |
152 |
> The thing is, we let commits flow directly from git to rsync. Good luck |
153 |
> with finding volunteers to be the gatekeepers for this. |
154 |
> |
155 |
> |
156 |
> I'm not sure I follow on this part. |
157 |
> |
158 |
> Today we let commits flow from git to rsync. This patch proposes that |
159 |
> emerge detect when deps of installed ebuilds change w/o a revbump. |
160 |
> These reports encourage *users* to take an action (file a bug.) |
161 |
> |
162 |
> I'm suggesting that we automate that action. |
163 |
> |
164 |
> "here is a report for x,y,z, file a bug? (Y/n)" |
165 |
> |
166 |
> And users hit Y and we file a bug report with a template and all the |
167 |
> required fields filled in (because emerge has them.) |
168 |
> |
169 |
> I'm not proposing a 'gatekeeper'. |
170 |
|
171 |
Okay, so how do we train users to deal with the fallout, given that |
172 |
there's no gate? |
173 |
-- |
174 |
Thanks, |
175 |
Zac |