Gentoo Archives: gentoo-portage-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-portage-dev@l.g.o, Alec Warner <antarus@g.o>
Cc: Zac Medico <zmedico@g.o>
Subject: Re: [gentoo-portage-dev] [PATCH] emerge: add --changed-deps-report option (bug 645780)
Date: Sun, 28 Jan 2018 20:17:01
Message-Id: 1517170612.5915.5.camel@gentoo.org
In Reply to: Re: [gentoo-portage-dev] [PATCH] emerge: add --changed-deps-report option (bug 645780) by Zac Medico
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

Replies