On 01/28/2018 12:16 PM, Michał Górny wrote: > W dniu nie, 28.01.2018 o godzinie 10∶09 -0800, użytkownik Zac Medico > napisał: >> On 01/28/2018 09:35 AM, Alec Warner wrote: >>> >>> >>> On Sun, Jan 28, 2018 at 9:51 AM, Zac Medico <zmed...@gentoo.org >>> <mailto:zmed...@gentoo.org>> wrote: >>> >>> The --dynamic-deps=n default causes confusion for users that are >>> accustomed to dynamic deps, therefore add a --changed-deps-report >>> option that is enabled by default (if --usepkgonly is not enabled). >>> >>> The --quiet option will suppress the report if none of the packages >>> having changed dependencies are in the dependency graph, since they >>> are harmless in that case. If any of these packages *are* in the >>> dependency graph, then --quiet suppresses the big NOTE section of >>> the report, but the HINT section is still displayed since it might >>> help users resolve problems that are solved by --changed-deps. >>> >>> Example output is as follows: >>> >>> !!! Detected ebuild dependency change(s) without revision bump: >>> >>> net-misc/openssh-7.5_p1-r3::gentoo >>> sys-fs/udisks-2.7.5::gentoo >>> >>> NOTE: For the ebuild(s) listed above, a new revision may be >>> warranted if there >>> has been a dependency change with significant consequences. >>> Refer to the >>> following page of the Gentoo Development Guide for examples of >>> circumstances that may qualify: >>> >>> >>> https://devmanual.gentoo.org/general-concepts/ebuild-revisions/ >>> <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/> >>> >>> If circumstances qualify, please report a bug which specifies >>> the current >>> version of the ebuild listed above. Changes to ebuilds from >>> the 'gentoo' >>> repository (ending with '::gentoo') can be browsed in GitWeb: >>> >>> https://gitweb.gentoo.org/repo/gentoo.git/ >>> <https://gitweb.gentoo.org/repo/gentoo.git/> >>> >>> Use Gentoo's Bugzilla to report bugs only for the 'gentoo' >>> repository: >>> >>> https://bugs.gentoo.org/ >>> >>> In order to suppress reports about dependency changes, add >>> --changed-deps-report=n to the EMERGE_DEFAULT_OPTS variable in >>> '/etc/portage/make.conf'. >>> >>> HINT: In order to avoid problems involving changed dependencies, use the >>> --changed-deps option to automatically trigger rebuilds when >>> changed >>> dependencies are detected. Refer to the emerge man page for more >>> information about this option. >>> >>> Bug: https://bugs.gentoo.org/645780 >>> >>> >>> I can't really support sending this large report to users. >>> >>> 1) Its fairly common practice today. >>> 2) All users will get the report. >>> 3) A subset of them will file bugs about the report. >>> 4) Devs make a decision about revbumping vs not; there doesn't seem to >>> be a way for devs to say "no this change is intentional, stop nagging >>> users." >> >> I think in practice we need to revbump for most changes. If the changes >> weren't worth propagating, then we wouldn't make them. > > It's not about 'being worth propagating', it's about 'being worth > the rebuild to propagate'. > > I've bumped dependency inside all LLVM ebuilds today. The change fixes > only problem that hits people who: > > a. don't use --deep when upgrading, > > b. use clang with LTO. > > I can't say how many people were hit by it since 5.0.0 was introduced > but yesterday I've got the first (and only) report so far. > > Yes, I could technically revbump and cause people to have to spend most > of the day rebuilding 1-2 versions of LLVM for change that doesn't make > any difference to them.
I can see how that would be troublesome for someone who runs ~arch and syncs once or more per day. For a stable user that syncs once a week or less often, it's an entirely different story. > Yes, I could consider the change 'not worth making'. But why shouldn't I > improve stuff for our users when it doesn't harm to do so? > > But with your suggested solution, now we no longer have the choice > 'revbump or not revbump'. Now we have a choice between forcing people to > rebuild via revbump or forcing people to get verbose report that most > likely will result in meaningless bug report and/or rebuild. So I end up > having a choice between 'force people to rebuild' or 'not fix minor bugs > at all'. Instead of suggesting to file a bug report, I think it should link to a wiki page that we will allow us to easily refine the content over time. Hopefully that will address everyone's concerns. My main intent is to provide a safety net for users, such that they'll be automatically notified that that --changed-deps option is available when needed to solve problems involving stale dependencies. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
