subpackaging kpatch-dnf means that a new version of both kpatch and
kpatch-dnf needs to be set for brew to accept the new package build.
Augment the kpatch-dnf subpackage version by prefixing the kpatch
version in order to satisfy brew in cases where only kpatch had its
version bumped
Resolves: rhbz#2121212
Signed-off-by: Yannick Cote <ycote@redhat.com>
kpatch-dnf subpackage 'Release' tag is always the same as parent
package's release so there is no value in dragging it along. Just remove
it so that parent package's 'Release' is always used.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Previous commits left a kpatch src rpm, for which now brew won't
overwrite:
GenericError: Error importing archive file, /mnt/brew/vol/rhel-9/packages/kpatch/0.9.2/3.el9/src/kpatch-0.9.2-3.el9.src.rpm already exists
So apparently the package and subpackage releases should move forward in
tandem. Let's try again with a new package release...
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
The kpatch-dnf description:
"kpatch-dnf is a DNF plugin than manages subcription ..."
should read:
"kpatch-dnf is a DNF plugin that manages subscription ..."
Resolves: rhbz#1934292
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Unlike kpatch and kpatch-dnf, python3 is not part of the BaseOS compose.
Hence, kpatch-dnf shouldn't depend on python3. Akin to other BaseOS dnf
plugins, depending on python3-dnf is enough and have a dependency on
system-python to have python3 ABI. (And kpatch-dnf is not shipped on
RHEL version having system-python with python2 ABI, so we don't have to
worry about that case)
Resolves: rhbz#1912457
Signed-off-by: Julien Thierry <jthierry@redhat.com>
The rhel-9.0.0-alpha branch is empty, so bring in all the files from the
rhel-8.4.0 branch.
Resolves: rhbz#1901593
Acked-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
