1 |
W dniu nie, 28.01.2018 o godzinie 10∶09 -0800, użytkownik Zac Medico |
2 |
napisał: |
3 |
> On 01/28/2018 09:35 AM, Alec Warner wrote: |
4 |
> > |
5 |
> > |
6 |
> > On Sun, Jan 28, 2018 at 9:51 AM, Zac Medico <zmedico@g.o |
7 |
> > <mailto:zmedico@g.o>> wrote: |
8 |
> > |
9 |
> > The --dynamic-deps=n default causes confusion for users that are |
10 |
> > accustomed to dynamic deps, therefore add a --changed-deps-report |
11 |
> > option that is enabled by default (if --usepkgonly is not enabled). |
12 |
> > |
13 |
> > The --quiet option will suppress the report if none of the packages |
14 |
> > having changed dependencies are in the dependency graph, since they |
15 |
> > are harmless in that case. If any of these packages *are* in the |
16 |
> > dependency graph, then --quiet suppresses the big NOTE section of |
17 |
> > the report, but the HINT section is still displayed since it might |
18 |
> > help users resolve problems that are solved by --changed-deps. |
19 |
> > |
20 |
> > Example output is as follows: |
21 |
> > |
22 |
> > !!! Detected ebuild dependency change(s) without revision bump: |
23 |
> > |
24 |
> > net-misc/openssh-7.5_p1-r3::gentoo |
25 |
> > sys-fs/udisks-2.7.5::gentoo |
26 |
> > |
27 |
> > NOTE: For the ebuild(s) listed above, a new revision may be |
28 |
> > warranted if there |
29 |
> > has been a dependency change with significant consequences. |
30 |
> > Refer to the |
31 |
> > following page of the Gentoo Development Guide for examples of |
32 |
> > circumstances that may qualify: |
33 |
> > |
34 |
> > |
35 |
> > https://devmanual.gentoo.org/general-concepts/ebuild-revisions/ |
36 |
> > <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/> |
37 |
> > |
38 |
> > If circumstances qualify, please report a bug which specifies |
39 |
> > the current |
40 |
> > version of the ebuild listed above. Changes to ebuilds from |
41 |
> > the 'gentoo' |
42 |
> > repository (ending with '::gentoo') can be browsed in GitWeb: |
43 |
> > |
44 |
> > https://gitweb.gentoo.org/repo/gentoo.git/ |
45 |
> > <https://gitweb.gentoo.org/repo/gentoo.git/> |
46 |
> > |
47 |
> > Use Gentoo's Bugzilla to report bugs only for the 'gentoo' |
48 |
> > repository: |
49 |
> > |
50 |
> > https://bugs.gentoo.org/ |
51 |
> > |
52 |
> > In order to suppress reports about dependency changes, add |
53 |
> > --changed-deps-report=n to the EMERGE_DEFAULT_OPTS variable in |
54 |
> > '/etc/portage/make.conf'. |
55 |
> > |
56 |
> > HINT: In order to avoid problems involving changed dependencies, use the |
57 |
> > --changed-deps option to automatically trigger rebuilds when |
58 |
> > changed |
59 |
> > dependencies are detected. Refer to the emerge man page for more |
60 |
> > information about this option. |
61 |
> > |
62 |
> > Bug: https://bugs.gentoo.org/645780 |
63 |
> > |
64 |
> > |
65 |
> > I can't really support sending this large report to users. |
66 |
> > |
67 |
> > 1) Its fairly common practice today. |
68 |
> > 2) All users will get the report. |
69 |
> > 3) A subset of them will file bugs about the report. |
70 |
> > 4) Devs make a decision about revbumping vs not; there doesn't seem to |
71 |
> > be a way for devs to say "no this change is intentional, stop nagging |
72 |
> > users." |
73 |
> |
74 |
> I think in practice we need to revbump for most changes. If the changes |
75 |
> weren't worth propagating, then we wouldn't make them. |
76 |
|
77 |
It's not about 'being worth propagating', it's about 'being worth |
78 |
the rebuild to propagate'. |
79 |
|
80 |
I've bumped dependency inside all LLVM ebuilds today. The change fixes |
81 |
only problem that hits people who: |
82 |
|
83 |
a. don't use --deep when upgrading, |
84 |
|
85 |
b. use clang with LTO. |
86 |
|
87 |
I can't say how many people were hit by it since 5.0.0 was introduced |
88 |
but yesterday I've got the first (and only) report so far. |
89 |
|
90 |
Yes, I could technically revbump and cause people to have to spend most |
91 |
of the day rebuilding 1-2 versions of LLVM for change that doesn't make |
92 |
any difference to them. |
93 |
|
94 |
Yes, I could consider the change 'not worth making'. But why shouldn't I |
95 |
improve stuff for our users when it doesn't harm to do so? |
96 |
|
97 |
But with your suggested solution, now we no longer have the choice |
98 |
'revbump or not revbump'. Now we have a choice between forcing people to |
99 |
rebuild via revbump or forcing people to get verbose report that most |
100 |
likely will result in meaningless bug report and/or rebuild. So I end up |
101 |
having a choice between 'force people to rebuild' or 'not fix minor bugs |
102 |
at all'. |
103 |
|
104 |
-- |
105 |
Best regards, |
106 |
Michał Górny |