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/...
--
Andrea Bolognani / Red Hat / Virtualization