On Sun, Jan 28, 2018 at 1:09 PM, Zac Medico <zmed...@gentoo.org> wrote:
> 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. > > > Ultimately I'm unsure what we are trying to accomplish here. Do we think > > Devs are doing 4 on accident? > > It doesn't matter whether it's intentional or an accident. The problem > is that users need to learn to react appropriately, and I think > --change-deps-report is probably the most efficient way to train them. > I guess I'm less convinced users can / should do it. Like they have to read the ebuild-revisions guide in the devmanual and decide if the revbump is required or not? Do we think users are able to do this? Should we consider only showing reports to developers (e.g. putting it behind a 'dev' FEATURE?) > > > If so, why can't we give them tools to find it ahead of time (repoman > > et. al.) or tools to find it post-commit (tinderbox or similar; but > > these are single-sourced reports.) > > Sure that can be done, but it will take some work. Honestly I think the > devs can get it right without all that, they just need some > reinforcement that has been absent up until now. > > Meanwhile, users need to be trained to cope with whatever comes their way. > > > I also feel like we are pushing action onto users here. If we agree with > > the premise that this is a bug (and devs should always bump) then we > > don't need users to take any action; > > I really do think that the devs can learn to get it right with a little > reinforcement. > > > we could build automation that sends these 'reports'. Its not like the > > user is going to add anything interesting to the report. Making them do > > it by hand just introduces transcription errors in filing. We just need > > to get their permission to file the reports automatically when portage > > finds them. > > The thing is, we let commits flow directly from git to rsync. Good luck > with finding volunteers to be the gatekeepers for this. > I'm not sure I follow on this part. Today we let commits flow from git to rsync. This patch proposes that emerge detect when deps of installed ebuilds change w/o a revbump. These reports encourage *users* to take an action (file a bug.) I'm suggesting that we automate that action. "here is a report for x,y,z, file a bug? (Y/n)" And users hit Y and we file a bug report with a template and all the required fields filled in (because emerge has them.) I'm not proposing a 'gatekeeper'. -A -- > Thanks, > Zac > >
