All platforms we target come with at least libvirt 6.0.0, so
none of the Obsoletes referring to earlier versions are useful
at this point.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
 libvirt.spec.in | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/libvirt.spec.in b/libvirt.spec.in
index b471afebb1..3e68961fb9 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -250,9 +250,6 @@ Requires: libvirt-daemon-driver-lxc = %{version}-%{release}
 %if %{with_qemu}
 Requires: libvirt-daemon-driver-qemu = %{version}-%{release}
 %endif
-# We had UML driver, but we've removed it.
-Obsoletes: libvirt-daemon-driver-uml <= 5.0.0
-Obsoletes: libvirt-daemon-uml <= 5.0.0
 %if %{with_vbox}
 Requires: libvirt-daemon-driver-vbox = %{version}-%{release}
 %endif
@@ -608,9 +605,6 @@ Requires: util-linux
 # From QEMU RPMs
 Requires: /usr/bin/qemu-img
 %endif
-%if !%{with_storage_rbd}
-Obsoletes: libvirt-daemon-driver-storage-rbd < 5.2.0
-%endif
 Obsoletes: libvirt-daemon-driver-storage-sheepdog < 8.8.0
 
 %description daemon-driver-storage-core
@@ -812,7 +806,6 @@ VirtualBox
 Summary: Libxl driver plugin for the libvirtd daemon
 Requires: libvirt-daemon-common = %{version}-%{release}
 Requires: libvirt-libs = %{version}-%{release}
-Obsoletes: libvirt-daemon-driver-xen < 4.3.0
 
 %description daemon-driver-libxl
 The Libxl driver plugin for the libvirtd daemon, providing
-- 
2.41.0

On Wed, Sep 06, 2023 at 11:31:10AM +0200, Andrea Bolognani wrote:
> All platforms we target come with at least libvirt 6.0.0, so
> none of the Obsoletes referring to earlier versions are useful
> at this point.

This rationale assumes that the upgrade is merely an
refresh of the current install. If a user is coming
from an earlier platform version to a modern platform
version, that original platform is likely unsupported,
but we still want the upgrade path to resolve these
obsoletes.

> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
>  libvirt.spec.in | 7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/libvirt.spec.in b/libvirt.spec.in
> index b471afebb1..3e68961fb9 100644
> --- a/libvirt.spec.in
> +++ b/libvirt.spec.in
> @@ -250,9 +250,6 @@ Requires: libvirt-daemon-driver-lxc = %{version}-%{release}
>  %if %{with_qemu}
>  Requires: libvirt-daemon-driver-qemu = %{version}-%{release}
>  %endif
> -# We had UML driver, but we've removed it.
> -Obsoletes: libvirt-daemon-driver-uml <= 5.0.0
> -Obsoletes: libvirt-daemon-uml <= 5.0.0
>  %if %{with_vbox}
>  Requires: libvirt-daemon-driver-vbox = %{version}-%{release}
>  %endif
> @@ -608,9 +605,6 @@ Requires: util-linux
>  # From QEMU RPMs
>  Requires: /usr/bin/qemu-img
>  %endif
> -%if !%{with_storage_rbd}
> -Obsoletes: libvirt-daemon-driver-storage-rbd < 5.2.0
> -%endif
>  Obsoletes: libvirt-daemon-driver-storage-sheepdog < 8.8.0
>  
>  %description daemon-driver-storage-core
> @@ -812,7 +806,6 @@ VirtualBox
>  Summary: Libxl driver plugin for the libvirtd daemon
>  Requires: libvirt-daemon-common = %{version}-%{release}
>  Requires: libvirt-libs = %{version}-%{release}
> -Obsoletes: libvirt-daemon-driver-xen < 4.3.0
>  
>  %description daemon-driver-libxl
>  The Libxl driver plugin for the libvirtd daemon, providing
> -- 
> 2.41.0
> 

With 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 :|

On Wed, Sep 06, 2023 at 11:07:10AM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 06, 2023 at 11:31:10AM +0200, Andrea Bolognani wrote:
> > All platforms we target come with at least libvirt 6.0.0, so
> > none of the Obsoletes referring to earlier versions are useful
> > at this point.
>
> This rationale assumes that the upgrade is merely an
> refresh of the current install. If a user is coming
> from an earlier platform version to a modern platform
> version, that original platform is likely unsupported,
> but we still want the upgrade path to resolve these
> obsoletes.

I'm happy to drop this patch as the impact of the cleanup is pretty
small anyway, but generally speaking I don't think that we should aim
to support scenarios such as the one you describe.

If someone is going from, say, Debian 10 to Debian 11, and they want
to move to an even newer version of libvirt than the one shipped with
the OS, this is what will happen:

  * they will start with the version in Debian 10 (5.0.0);

  * they will upgrade the system to Debian 11, which will bring the
    version of libvirt up to 7.0.0, obsoleting packages as necessary
    in the process;

  * they will build the latest version of libvirt from source and
    install it.

Trying to jump from 5.0.0 to the latest upstream version without
going through 7.0.0 will require additional steps and generally be
fiddly as heck, for no obvious advantage.

With that in mind, I think my patch is perfectly good and does
nothing to harm the experience of someone upgrading from a platform
that we no longer target to one that we still do.

-- 
Andrea Bolognani / Red Hat / Virtualization

On Wed, Sep 06, 2023 at 07:26:55AM -0400, Andrea Bolognani wrote:
> On Wed, Sep 06, 2023 at 11:07:10AM +0100, Daniel P. Berrangé wrote:
> > On Wed, Sep 06, 2023 at 11:31:10AM +0200, Andrea Bolognani wrote:
> > > All platforms we target come with at least libvirt 6.0.0, so
> > > none of the Obsoletes referring to earlier versions are useful
> > > at this point.
> >
> > This rationale assumes that the upgrade is merely an
> > refresh of the current install. If a user is coming
> > from an earlier platform version to a modern platform
> > version, that original platform is likely unsupported,
> > but we still want the upgrade path to resolve these
> > obsoletes.
> 
> I'm happy to drop this patch as the impact of the cleanup is pretty
> small anyway, but generally speaking I don't think that we should aim
> to support scenarios such as the one you describe.
> 
> If someone is going from, say, Debian 10 to Debian 11, and they want
> to move to an even newer version of libvirt than the one shipped with
> the OS, this is what will happen:
> 
>   * they will start with the version in Debian 10 (5.0.0);
> 
>   * they will upgrade the system to Debian 11, which will bring the
>     version of libvirt up to 7.0.0, obsoleting packages as necessary
>     in the process;
> 
>   * they will build the latest version of libvirt from source and
>     install it.
> 
> Trying to jump from 5.0.0 to the latest upstream version without
> going through 7.0.0 will require additional steps and generally be
> fiddly as heck, for no obvious advantage.
> 
> With that in mind, I think my patch is perfectly good and does
> nothing to harm the experience of someone upgrading from a platform
> that we no longer target to one that we still do.

Consider earlier versions of RHEL-8 shipped libvirt 4.5.0, and if
we rebase libvirt again in RHEL-9, an upgrade from RHEL 8.3 to
RHEL-9 will need this Obsoletes condition that is being removed.
A RHEL-8 to RHEL-9 upgrade path is an expected scenario to be
supported.

With 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 :|

On Wed, Sep 06, 2023 at 12:29:15PM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 06, 2023 at 07:26:55AM -0400, Andrea Bolognani wrote:
> > I'm happy to drop this patch as the impact of the cleanup is pretty
> > small anyway, but generally speaking I don't think that we should aim
> > to support scenarios such as the one you describe.
> >
> > If someone is going from, say, Debian 10 to Debian 11, and they want
> > to move to an even newer version of libvirt than the one shipped with
> > the OS, this is what will happen:
> >
> >   * they will start with the version in Debian 10 (5.0.0);
> >
> >   * they will upgrade the system to Debian 11, which will bring the
> >     version of libvirt up to 7.0.0, obsoleting packages as necessary
> >     in the process;
> >
> >   * they will build the latest version of libvirt from source and
> >     install it.
> >
> > Trying to jump from 5.0.0 to the latest upstream version without
> > going through 7.0.0 will require additional steps and generally be
> > fiddly as heck, for no obvious advantage.
> >
> > With that in mind, I think my patch is perfectly good and does
> > nothing to harm the experience of someone upgrading from a platform
> > that we no longer target to one that we still do.
>
> Consider earlier versions of RHEL-8 shipped libvirt 4.5.0, and if
> we rebase libvirt again in RHEL-9, an upgrade from RHEL 8.3 to
> RHEL-9 will need this Obsoletes condition that is being removed.
> A RHEL-8 to RHEL-9 upgrade path is an expected scenario to be
> supported.

That's explicitly unsupported[1]: the earliest version of RHEL 8 that
you can use as a starting point for an upgrade to RHEL 9 is RHEL 8.6,
which has libvirt 8.0.0.


[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/upgrading_from_rhel_8_to_rhel_9/con_supported-upgrade-paths_upgrading-from-rhel-8-to-rhel-9
-- 
Andrea Bolognani / Red Hat / Virtualization

On Wed, Sep 06, 2023 at 08:15:01AM -0400, Andrea Bolognani wrote:
> On Wed, Sep 06, 2023 at 12:29:15PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Sep 06, 2023 at 07:26:55AM -0400, Andrea Bolognani wrote:
> > > I'm happy to drop this patch as the impact of the cleanup is pretty
> > > small anyway, but generally speaking I don't think that we should aim
> > > to support scenarios such as the one you describe.
> > >
> > > If someone is going from, say, Debian 10 to Debian 11, and they want
> > > to move to an even newer version of libvirt than the one shipped with
> > > the OS, this is what will happen:
> > >
> > >   * they will start with the version in Debian 10 (5.0.0);
> > >
> > >   * they will upgrade the system to Debian 11, which will bring the
> > >     version of libvirt up to 7.0.0, obsoleting packages as necessary
> > >     in the process;
> > >
> > >   * they will build the latest version of libvirt from source and
> > >     install it.
> > >
> > > Trying to jump from 5.0.0 to the latest upstream version without
> > > going through 7.0.0 will require additional steps and generally be
> > > fiddly as heck, for no obvious advantage.
> > >
> > > With that in mind, I think my patch is perfectly good and does
> > > nothing to harm the experience of someone upgrading from a platform
> > > that we no longer target to one that we still do.
> >
> > Consider earlier versions of RHEL-8 shipped libvirt 4.5.0, and if
> > we rebase libvirt again in RHEL-9, an upgrade from RHEL 8.3 to
> > RHEL-9 will need this Obsoletes condition that is being removed.
> > A RHEL-8 to RHEL-9 upgrade path is an expected scenario to be
> > supported.
> 
> That's explicitly unsupported[1]: the earliest version of RHEL 8 that
> you can use as a starting point for an upgrade to RHEL 9 is RHEL 8.6,
> which has libvirt 8.0.0.

I don't care for docs that place such artifical constraints on the
the upgrade process, because in practice many users are not going
to read that doc, and even those who did read it are liable to go
ahead regardless. I don't see it being compelling to break the
upgrade path

With 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 :|

On Wed, Sep 06, 2023 at 01:23:25PM +0100, Daniel P. Berrangé wrote:
> I don't care for docs that place such artifical constraints on the
> the upgrade process, because in practice many users are not going
> to read that doc, and even those who did read it are liable to go
> ahead regardless. I don't see it being compelling to break the
> upgrade path

Alright, let's try again in a few years then :)

-- 
Andrea Bolognani / Red Hat / Virtualization