Issues #55 and #56 root in that the plugin is run in the context of the builder, with these drawbacks:

• The Koji builder is agnostic about the version of the distribution (i.e. what ends up in the %dist tag), we need this to figure out a suitable release number.
• To avoid inadvertently attempting to build SRPMs or packages in the builder (and only in build roots), it doesn't have the rpm-build package installed ⇒ no rpmspec command ⇒ rpm --specfile ... doesn't work (which we use to figure out the version of the package being built).

Generating the new release tag and changelog in the build root would circumvent these problems:

• The rpm-build package is installed, it's used to build the SRPM.
• It contains the fedora-release-common package, i.e. /usr/lib/rpm/macros.d/macros.dist which defines %fedora and %dist, i.e. we can do rpm --eval %dist and use that as an input for our code

Right now, the build root isn't exposed (well) to the plugin callback (see this part of the kojid code). Possible approaches to get hold of it:

• Steal the broot object from BuildSRPMFromSCMTask.handler() ("dirty"). This method ultimately causes our callback to be run. Outlined here: https://pagure.io/steal-object-from-caller
• Let this method pass the broot object directly into the called plugin callbacks ("clean").
• Let this method pass broot.id and self.options into the callbacks, then our callback could "borrow" the BuildRoot class (from __main__ import BuildRoot, this is going to make writing tests fun) and reuse the existing build root by instantiating the class with these two parameters and session which it has already ("not really clean").

One thing that still needs to be done in the context of the builder rather than the build root is tagging existing builds because it needs a Koji client session which we have there, see issue #44 (and #42, #43).