Re: [gentoo-portage-dev] [PATCH] emerge: add --changed-deps-report option (bug 645780)

[Zac Medico]

On 01/28/2018 10:47 AM, Alec Warner wrote:
>
>
> On Sun, Jan 28, 2018 at 1:09 PM, Zac Medico <zmedico@g.o
> <mailto:zmedico@g.o>> wrote:
>
>     On 01/28/2018 09:35 AM, Alec Warner wrote:
>     >
>     >
>     > On Sun, Jan 28, 2018 at 9:51 AM, Zac Medico <zmedico@g.o <mailto:zmedico@g.o>
>     > <mailto:zmedico@g.o <mailto:zmedico@g.o>>> 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/>
>     >   
>      <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/>
>     >     <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?

Maybe some. The worst case is that they file a bug and the developer
gets to see a useful message in the bug report.

I don't expect this case to be the norm, because I expect that
developers usually do the right thing given the necessary reinforcement.

> Should we consider only showing reports to developers (e.g. putting it
> behind a 'dev' FEATURE?)

What are the users supposed to do if they have dependency calculation
failure and they don't know about the --changed-deps option? Why not
instantly notified them that the --changed-deps option is available to
solve their problems?

Again, I don't expect this case to be the norm. It's a safety net.

>     > 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'.

Okay, so how do we train users to deal with the fallout, given that
there's no gate?
-- 
Thanks,
Zac