This request is superseded by
request 1127309
(Show diff)
Overview
Request 1127234 superseded
- Update to version 1.1.0
Release notes https://github.com/kubevirt/kubevirt/releases/tag/v1.1.0
- Created by vulyanov
- In state superseded
- Superseded by 1127309
- Open review for opensuse-review-team
- Open review for openSUSE:Factory:Staging:adi:16
Loading...
Request History
vulyanov created request
- Update to version 1.1.0
Release notes https://github.com/kubevirt/kubevirt/releases/tag/v1.1.0
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
staging-bot added openSUSE:Factory:Staging:adi:16 as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:16"
staging-bot accepted review
Picked "openSUSE:Factory:Staging:adi:16"
- Update to version 1.1.0
Release notes https://github.com/kubevirt/kubevirt/releases/tag/v1.1.0
The path
/usr/bin/virt-tail
is correct, and the tool is invoked by the upstream code using that full path.kubevirt-virt-launcher-1.1.0-1.1.x86_64
rpm is not supposed to be installed on the host system. It should be consumed only by the respective container image https://build.opensuse.org/package/view_file/Virtualization/virt-launcher-container/Dockerfile?expand=1. Considering that, can we just ignore the conflict? Or what the proper way of packaging the binary might be? I can install the binary into some weird location and then move it in the Dockerfile. But this looks more like an ugly hack.Ignoring is not an option - but you can declare the two packages as conflicting in the spec file using
Conflicts:
Right, but I assume
Conflicts:
will need to be specified in bothguestfs-tools
andkubevirt-virt-launcher
.one side declaring it is sufficient
Ah.. I thought it should be declared on both sides... Okay, will resubmit. Thx!