Re: [libvirt] [PATCH] rpm: fix upgrades when RBD is disabled in a new version
On Wed, Mar 20, 2019 at 01:01:52PM +0100, Erik Skultety wrote:
On Tue, Mar 19, 2019 at 04:00:59PM +0000, Daniel P. Berrangé wrote:
> We previously had to disable RBD on 32-bit platforms since Ceph has
> dropped all support for 32-bit. Unfortunately anyone with the RPM
> libvirt-daemon-driver-storage-rbd installed on 32-bit now has a
> broken upgrade path.
>
> To fix this we must make libvirt-daemon-driver-storage-common
s/common/core
> have an Obsoletes: libvirt-daemon-driver-storage-rbd < $VER-$REL
>
> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
> ---
Reviewed-by: Erik Skultety <eskultet(a)redhat.com>
> libvirt.spec.in | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libvirt.spec.in b/libvirt.spec.in
> index 1497cad3d2..79f3d31d19 100644
> --- a/libvirt.spec.in
> +++ b/libvirt.spec.in
> @@ -550,6 +550,9 @@ Requires: util-linux
> # From QEMU RPMs
> Requires: /usr/bin/qemu-img
> %endif
> +%if !%{with_storage_rbd}
> +Obsoletes: libvirt-daemon-driver-storage-rbd < %{version}-%{release}
Which version did we disable it? I'm asking because we have a similar check for
xen, but we specified it as < 4.3.0
I don't think we need to use a fixed version that matches when it
was disabled. Indeed the need to disable is not actually tied to
the libvirt version, rather the version of Ceph you are building
libvirt against. So the version at which we added the RPM spec
change is not relevant. We just have to mark it as Obsoleted
any time we build libvirt without it, regardless of version.
The xen situation was different, as in that case it was actually
a specific libvirt release that deleted the legacy Xen driver
sub-RPM, so tieing to that version is fine.
Reviewed-by: Erik Skultety <eskultet(a)redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|