[ovs-dev,v2] rhel: bug fix upgrade path in kmod fedora spec file

Message ID 20181213173034.53455-1-martinxu9.ovs@gmail.com
State New
Headers show
Series
  • [ovs-dev,v2] rhel: bug fix upgrade path in kmod fedora spec file
Related show

Commit Message

Martin Xu Dec. 13, 2018, 5:30 p.m.
This patch removes the "Conflicts" tag and adds "Obsoletes" tag.

With the conflicts tag, when a user attempts to install or upgrade with
the same version as already installed, the conflict kicks in. Otherwise,
such is allowed with --replacepkgs.

Obsoletes is needed for the upgrade path from kmod-openvswitch to
openvswitch-kmod.

Fixes: 22c33c3039 (rhel: support kmod build against mulitple kernel
versions, fedora)

VMware-BZ: #2249788

Signed-off-by: Martin Xu <martinxu9.ovs@gmail.com>
CC: Flavio Leitner <fbl@sysclose.org>
CC: Yi-Hung Wei <yihung.wei@gmail.com>
CC: Yifeng Sun <pkusunyifeng@gmail.com>
CC: Zak Whittington <zwhitt.vmware@gmail.com>
CC: Ben Pfaff <blp@ovn.org>
---
v1->v2: adds "Obsoletes" tag needed for upgrade after renaming
        adds more reviewers

 rhel/openvswitch-kmod-fedora.spec.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Martin Xu Dec. 13, 2018, 10:50 p.m. | #1
Hi Flavio,

I remember when we had a discussion about package "succession" when I had
the "Obsoletes" tag added in one of the previous patches submitted for the
fedora spec files.

We do need the capability for the system to know openvswitch-kmod is
automatically upgrading kmod-openvswitch. For some reason, I thought I
tested "Provides" alone would suffice. I just tried again and it seems not
the case. "Provides" does not make the renamed package automatically
upgrade the older one. Is there any other ways of doing this? I found one
suggestion from the fedora site, that uses both "Provides" and "Obsoletes."
I understand this means we will be declaring openvswitch-kmod is being
replaced. We can't go either way anymore. Is there a better solution?
Thanks.

Martin

On Thu, Dec 13, 2018 at 2:44 PM Martin Xu <martinxu9.ovs@gmail.com> wrote:

> This patch removes the "Conflicts" tag and adds "Obsoletes" tag.
>
> With the conflicts tag, when a user attempts to install or upgrade with
> the same version as already installed, the conflict kicks in. Otherwise,
> such is allowed with --replacepkgs.
>
> Obsoletes is needed for the upgrade path from kmod-openvswitch to
> openvswitch-kmod.
>
> Fixes: 22c33c3039 (rhel: support kmod build against mulitple kernel
> versions, fedora)
>
> VMware-BZ: #2249788
>
> Signed-off-by: Martin Xu <martinxu9.ovs@gmail.com>
> CC: Flavio Leitner <fbl@sysclose.org>
> CC: Yi-Hung Wei <yihung.wei@gmail.com>
> CC: Yifeng Sun <pkusunyifeng@gmail.com>
> CC: Zak Whittington <zwhitt.vmware@gmail.com>
> CC: Ben Pfaff <blp@ovn.org>
> ---
> v1->v2: adds "Obsoletes" tag needed for upgrade after renaming
>         adds more reviewers
>
>  rhel/openvswitch-kmod-fedora.spec.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rhel/openvswitch-kmod-fedora.spec.in b/rhel/
> openvswitch-kmod-fedora.spec.in
> index 8d54fd734..7913dbdb4 100644
> --- a/rhel/openvswitch-kmod-fedora.spec.in
> +++ b/rhel/openvswitch-kmod-fedora.spec.in
> @@ -33,7 +33,7 @@ Source: openvswitch-%{version}.tar.gz
>  #Source1: openvswitch-init
>  Buildroot: /tmp/openvswitch-xen-rpm
>  Provides: kmod-openvswitch
> -Conflicts: kmod-openvswitch
> +Obsoletes: kmod-openvswitch
>
>  %description
>  Open vSwitch provides standard network bridging functions augmented with
> --
> 2.12.3
>
>
Gregory Rose Dec. 19, 2018, 10:20 p.m. | #2
Flavio,

I was hoping you would have time to check this patch?

Thanks,

- Greg

On 12/13/2018 2:50 PM, Martin Xu wrote:
> Hi Flavio,
>
> I remember when we had a discussion about package "succession" when I had
> the "Obsoletes" tag added in one of the previous patches submitted for the
> fedora spec files.
>
> We do need the capability for the system to know openvswitch-kmod is
> automatically upgrading kmod-openvswitch. For some reason, I thought I
> tested "Provides" alone would suffice. I just tried again and it seems not
> the case. "Provides" does not make the renamed package automatically
> upgrade the older one. Is there any other ways of doing this? I found one
> suggestion from the fedora site, that uses both "Provides" and "Obsoletes."
> I understand this means we will be declaring openvswitch-kmod is being
> replaced. We can't go either way anymore. Is there a better solution?
> Thanks.
>
> Martin
>
> On Thu, Dec 13, 2018 at 2:44 PM Martin Xu <martinxu9.ovs@gmail.com> wrote:
>
>> This patch removes the "Conflicts" tag and adds "Obsoletes" tag.
>>
>> With the conflicts tag, when a user attempts to install or upgrade with
>> the same version as already installed, the conflict kicks in. Otherwise,
>> such is allowed with --replacepkgs.
>>
>> Obsoletes is needed for the upgrade path from kmod-openvswitch to
>> openvswitch-kmod.
>>
>> Fixes: 22c33c3039 (rhel: support kmod build against mulitple kernel
>> versions, fedora)
>>
>> VMware-BZ: #2249788
>>
>> Signed-off-by: Martin Xu <martinxu9.ovs@gmail.com>
>> CC: Flavio Leitner <fbl@sysclose.org>
>> CC: Yi-Hung Wei <yihung.wei@gmail.com>
>> CC: Yifeng Sun <pkusunyifeng@gmail.com>
>> CC: Zak Whittington <zwhitt.vmware@gmail.com>
>> CC: Ben Pfaff <blp@ovn.org>
>> ---
>> v1->v2: adds "Obsoletes" tag needed for upgrade after renaming
>>          adds more reviewers
>>
>>   rhel/openvswitch-kmod-fedora.spec.in | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/rhel/openvswitch-kmod-fedora.spec.in b/rhel/
>> openvswitch-kmod-fedora.spec.in
>> index 8d54fd734..7913dbdb4 100644
>> --- a/rhel/openvswitch-kmod-fedora.spec.in
>> +++ b/rhel/openvswitch-kmod-fedora.spec.in
>> @@ -33,7 +33,7 @@ Source: openvswitch-%{version}.tar.gz
>>   #Source1: openvswitch-init
>>   Buildroot: /tmp/openvswitch-xen-rpm
>>   Provides: kmod-openvswitch
>> -Conflicts: kmod-openvswitch
>> +Obsoletes: kmod-openvswitch
>>
>>   %description
>>   Open vSwitch provides standard network bridging functions augmented with
>> --
>> 2.12.3
>>
>>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Flavio Leitner Jan. 3, 2019, 5:44 p.m. | #3
Hi Martin,

Sorry the delay, coming back from PTO and holidays.

On Thu, Dec 13, 2018 at 02:50:22PM -0800, Martin Xu wrote:
> Hi Flavio,
> 
> I remember when we had a discussion about package "succession" when I had
> the "Obsoletes" tag added in one of the previous patches submitted for the
> fedora spec files.
> 
> We do need the capability for the system to know openvswitch-kmod is
> automatically upgrading kmod-openvswitch. For some reason, I thought I
> tested "Provides" alone would suffice. I just tried again and it seems not
> the case. "Provides" does not make the renamed package automatically
> upgrade the older one. Is there any other ways of doing this? I found one
> suggestion from the fedora site, that uses both "Provides" and "Obsoletes."
> I understand this means we will be declaring openvswitch-kmod is being
> replaced. We can't go either way anymore. Is there a better solution?
> Thanks.

Provides does not allow upgrades. It will satisfy dependencies on what
you are providing. A common example is smtp: sendmail and postfix. Both
could do: "Provides: smtp", then "mutt" could do "Requires: smtp" and
either sendmail or postfix would be fine.

You're right that you need Obsoletes to allow upgrades. The problem
with Obsoletes is that once you ship it, there is no turning back.
That's why I suggested to limit to a specific version.
For example:

   Obsoletes: kmod-openvswitch < %{version}-%{release}

That grants all previous packages are indeed obsoleted while it
would be possible to resurrect kmod-openvswitch if we change our minds
in the future. All we would need is to ship kmod-openvswitch newer
than the last %{version}-%{release} shipped.

HTH,
fbl

> 
> Martin
> 
> On Thu, Dec 13, 2018 at 2:44 PM Martin Xu <martinxu9.ovs@gmail.com> wrote:
> 
> > This patch removes the "Conflicts" tag and adds "Obsoletes" tag.
> >
> > With the conflicts tag, when a user attempts to install or upgrade with
> > the same version as already installed, the conflict kicks in. Otherwise,
> > such is allowed with --replacepkgs.
> >
> > Obsoletes is needed for the upgrade path from kmod-openvswitch to
> > openvswitch-kmod.
> >
> > Fixes: 22c33c3039 (rhel: support kmod build against mulitple kernel
> > versions, fedora)
> >
> > VMware-BZ: #2249788
> >
> > Signed-off-by: Martin Xu <martinxu9.ovs@gmail.com>
> > CC: Flavio Leitner <fbl@sysclose.org>
> > CC: Yi-Hung Wei <yihung.wei@gmail.com>
> > CC: Yifeng Sun <pkusunyifeng@gmail.com>
> > CC: Zak Whittington <zwhitt.vmware@gmail.com>
> > CC: Ben Pfaff <blp@ovn.org>
> > ---
> > v1->v2: adds "Obsoletes" tag needed for upgrade after renaming
> >         adds more reviewers
> >
> >  rhel/openvswitch-kmod-fedora.spec.in | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/rhel/openvswitch-kmod-fedora.spec.in b/rhel/
> > openvswitch-kmod-fedora.spec.in
> > index 8d54fd734..7913dbdb4 100644
> > --- a/rhel/openvswitch-kmod-fedora.spec.in
> > +++ b/rhel/openvswitch-kmod-fedora.spec.in
> > @@ -33,7 +33,7 @@ Source: openvswitch-%{version}.tar.gz
> >  #Source1: openvswitch-init
> >  Buildroot: /tmp/openvswitch-xen-rpm
> >  Provides: kmod-openvswitch
> > -Conflicts: kmod-openvswitch
> > +Obsoletes: kmod-openvswitch
> >
> >  %description
> >  Open vSwitch provides standard network bridging functions augmented with
> > --
> > 2.12.3
> >
> >
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Patch

diff --git a/rhel/openvswitch-kmod-fedora.spec.in b/rhel/openvswitch-kmod-fedora.spec.in
index 8d54fd734..7913dbdb4 100644
--- a/rhel/openvswitch-kmod-fedora.spec.in
+++ b/rhel/openvswitch-kmod-fedora.spec.in
@@ -33,7 +33,7 @@  Source: openvswitch-%{version}.tar.gz
 #Source1: openvswitch-init
 Buildroot: /tmp/openvswitch-xen-rpm
 Provides: kmod-openvswitch
-Conflicts: kmod-openvswitch
+Obsoletes: kmod-openvswitch
 
 %description
 Open vSwitch provides standard network bridging functions augmented with