Hello all,
Again thanks for the help!!!
On 10/26/2017 09:09 PM, Kevin Kofler wrote:
> William Moreno wrote:
>> Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release}
>>
>> Move this line under
>>
>> %package -n libnfsidmap-devel
>>
>> And you should get a clean update path
>
> As Hedayat Vatankhah pointed out, if the package is called libnfsidmap-
> devel, it does not actually need to Provide itself. So the
> Obsoletes/Provides should go away entirely.
>
> Obsoletes/Provides are needed if the BINARY package name changes. E.g., if
> we had:
> %package libnfsidmap-devel
> (without the -n), generating a nfs-utils-libnfsidmap-devel subpackage, THEN
> it would make sense to Obsolete and Provide libnfsidmap-devel in that
> subpackage (NOT in the main package). But since %package -n is used to
> recreate the same old package name, there is nothing to Obsolete and Provide
> to begin with.
I follow what you are saying but... when I remove both the Obsolete and Provide
for libnfsidmap-devel (only Provides: libnfsidmap is set in the nfs-utils section)
the upgrade still wants to remove libnfsidmap-devel package instead of upgrading it.
If you have a libnfsidmap subpackage, do NOT include "Provides: libnfsidmap" on the 'nfs-utils' subpackage. They will get in each others' way.
I assume that the intent here is to move libnfsidmap from being its own SRPM to being a subpackage of the nfs-utils package, right? You don't need to have nfs-utils Provides: or Obsoletes: anything. Just make sure that the libnfsidmap is sorted higher than the previous standalone version and it should Just Work.