# Copr impact check

## Check what packages (transitively) BuildRequire your package

$ repoquery --repo=rawhide{,-source} --whatrequires python3-foo --recursive | grep src$ | pkgname | sort | uniq > packages.txt

Use `--repo={fedora,updates}{,-source} --releasever XX --latest=1` instead of `--repo=rawhide{,-source}` for older releases.
XXX: what does `--latest=1` mean?

Always use the package name for this, not a virtual provide.

Note that the `--recursive` flag might give an enormous list of packages (e.g. for python3-setuptools), so feel free to not always use it.

## Check what packages might not even install the new version

RE: https://github.com/fedora-python/pull-request-review-guide/blob/main/fedora-pr-review-guide.md#impact-check---when-to-do-it

This is a big hack to find any build or runtime dependencies such as `BuildRequires: foo < 4` or `Requires: foo < 4`. It gets all requirements of your package and greps them for `<` (packages with an upper limit to the version). Note that the `'\bfoo\b'` regex will not work correctly for your package (unless named foo). The idea is to grep for all requires of your package, so it must match both `python3-foo` and `python3.Xdist(foo)` etc. Replace it with a regex that fits your use case. False matches are not that bad, unless there is too many of them, so the regex does not usually need to be very specific.

### Fast check

Does not reveal affected package names, but can be used for a quick check to see if the slow check is even neccessary

$ repoquery -q --repo=rawhide{,-source} --requires -a | grep -E '\bfoo\b' | grep '<'

(Reminder: Use `--repo={fedora,updates}{,-source} --releasever XX --latest=1` instead of `--repo=rawhide{,-source}` for older releases.)

### Slower check

Runs potentially many repoqueries in a loop, so it's slow, but shows affected packages, if any

$ for pkg in $(repoquery -q --repo=rawhide{,-source} --whatrequires python3-foo); do repoquery -q --repo=rawhide{,-source} --requires $pkg | grep -E '\bfoo\b' | grep '<' && echo -e "${pkg}\n"; done

(Reminder: Use `--repo={fedora,updates}{,-source} --releasever XX --latest=1` instead of `--repo=rawhide{,-source}` for older releases.)

### Verbose Example (Modified Slower Check)

# Package name in repoquery
NAME_REPO="python3-CacheControl"
# Package name in dist - may not match above eg. upper/camel vs lower
# Alternatively, change `grep -E` to `grep -Ei` though you may get more results than intended
NAME_DIST="cachecontrol"

for pkg in $(repoquery -q --repo=rawhide{,-source} --whatrequires $NAME_REPO);
do 
    echo -e "${pkg}"
    repoquery -q --repo=rawhide{,-source} --requires $pkg | \
    grep -E "\b$NAME_DIST\b" | \
    grep '<' &&
    echo ||
    printf "#NONE FOUND#\n"
done

## Create a copr and build your package in it

Push the updated package to your fork on https://src.fedoraproject.org and run the following.

$ COPR=foo-3.2.1
$ copr create \
       $COPR \
       --repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/' \
       --chroot fedora-rawhide-x86_64 \
       --delete-after-days 30

$ copr add-package-distgit \
       $COPR \
       --name $(fedpkg --release rawhide verrel | pkgname) \
       --commit $(git branch --show-current) \
       --namespace forks/$(whoami) \
       --webhook-rebuild on

$ copr build-package $COPR --name $(fedpkg --release rawhide verrel | pkgname)

For older releases:

$ COPR=fXX-foo-3.2.1
$ copr create $COPR --repo='http://kojipkgs.fedoraproject.org/repos/fXX-build/latest/$basearch/' --chroot fedora-XX-x86_64 --delete-after-days 30
$ copr add-package-distgit $COPR --name $(fedpkg --release fXX verrel | pkgname) --commit $(git branch --show-current) --namespace forks/$(whoami) --webhook-rebuild on
$ copr build-package $COPR --name $(fedpkg --release fXX verrel | pkgname)

If you don't want to push to your fork yet, instead do:

$ COPR=foo-3.2.1
$ copr create \
       $COPR \
       --repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/' \
       --chroot fedora-rawhide-x86_64 \
       --delete-after-days 30
$ fedpkg --release rawhide copr-build $COPR

Wait for the build to finish and succeed.

## Build all the dependents

See also https://docs.pagure.org/copr.copr/user_documentation.html#mass-rebuilds

Using `parallel` from the `moreutils-parallel` package.

$ parallel copr add-package-distgit $COPR --webhook-rebuild on --commit rawhide --name -- $(cat packages.txt)
$ parallel copr build-package $COPR --background --nowait --name -- $(cat packages.txt)

For older releases:

$ parallel copr add-package-distgit $COPR --webhook-rebuild on --commit fXX --name -- $(cat packages.txt)
$ parallel copr build-package $COPR --background --nowait --name -- $(cat packages.txt)

## Rebuild failures in a control COPR

$ copr monitor foo-3.2.1 --output-format text-row --fields name,state | grep failed$ | cut -f1 > failures.txt
$ COPR=foo-3.1.0  # the current rawhide version
$ copr create $COPR --repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/' --chroot fedora-rawhide-x86_64 --delete-after-days 30
$ parallel copr add-package-distgit $COPR --webhook-rebuild on --commit rawhide --name -- $(cat failures.txt)
$ parallel copr build-package $COPR --background --nowait --name -- $(cat failures.txt)

For older releases:

$ copr monitor fXX-foo-3.2.1 --output-format text-row --fields name,state | grep failed$ | cut -f1 > failures.txt
$ COPR=fXX-foo-3.1.0  # the current version
$ copr create $COPR --repo='http://kojipkgs.fedoraproject.org/repos/fXX-build/latest/$basearch/' --chroot fedora-XX-x86_64 --delete-after-days 30
$ parallel copr add-package-distgit $COPR --webhook-rebuild on --commit fXX --name -- $(cat failures.txt)
$ parallel copr build-package $COPR --background --nowait --name -- $(cat failures.txt)

## Get only packages that fail with the updated thing you are testing

comm -12 <(copr monitor foo-3.2.1 --output-format text-row --fields name,state | grep failed$ | cut -f1 | sort) <(copr monitor foo-3.1.0 --output-format text-row --fields name,state | grep succeeded$ | cut -f1 | sort)

(If you get more than is easy to inspect manually, you better resubmit those to the new copr in case it was a transient issue.)

## Have I built it all?

Sometimes, copr replies with:

Something went wrong:
Error: Response is not in JSON format, there is probably a bug in the API code.

And a build might have been skipped. Especially with a large dep-list, it's hard to check manually what package was not submitted. You can use:

comm -13 <(copr monitor $COPR --output-format text-row --fields name | sort) <(sort packages.txt)

## Advanced: Avoid transient build failures by building packages in an isolated Copr "directory"

Copr has a functionality called *directories*.

tl;dr Builds are by default built in the directory named after the copr project. However, builds can be submitted to be built in a different directory. Directories other than the default don't create DNF repositories and hence "don't see each other". When you use this feature packages won't fail to build just because you built something in your copr that was not yet built in Fedora proper.

For example: A package maintainer committed an update of python-itsdangerous to version 6.6.6 to Fedora dist-git. But they have not built it yet in Fedora, for whatever reason. You are performing an impact check for an update of python-setuptools. Once you build python-itsdangerous 6.6.6 in your copr (as it requires setuptools), other packages in your copr that depend on itsdangerous might start to fail, but not because of setuptools update, but because of itsdangerous update. Following the steps bellow will spare you from this unfortunate situation.

Follow the normal impact check guide with the following modifications (both for the impact check copr and the control copr):

1. Create the copr project and build the updated package(s) as you would normally do.
2. When building the dependent packages, use `$COPR:custom:isolated` as the copr name. This is the directory name and all packages can share the same one, as builds in directories other than the default don't have a DNF repository attached to them. (We've been asked to use whatever name we want as long as it is prefixed by `$COPR:custom:`, `$COPR:custom:isolated` is just what Miro uses, it works the same with `$COPR:custom:platypus` or `$COPR:custom:666`.)
3. When running `copr monitor` add `--dir $COPR:custom:isolated`. Note that if `$COPR` contains an owner (such as `@python/wheel-0.40` or `churchyard/setuptools-85`), the `--dir` argument must be without it -- e.g. `copr monitor @python/wheel-0.40 --dir wheel-0.40:custom:isolated ...`.