On Fri, Oct 27, 2017 at 12:25 PM Steve Dickson <ste...@redhat.com> wrote:
> > > On 10/27/2017 11:47 AM, Steve Dickson wrote: > > Hello, > > > > On 10/27/2017 11:11 AM, Stephen Gallagher wrote: > >> > >> > >> On Fri, Oct 27, 2017 at 10:55 AM Steve Dickson <ste...@redhat.com > <mailto:ste...@redhat.com>> wrote: > >> > >> 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? > > Yes. > > > >> 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. > > This makes sense but the reason the libnfsidmap-devel package is not > > be upgraded (or installed) is because: > > > > dnf install /tmp/libnfsidmap-devel* > > Last metadata expiration check: 0:10:48 ago on Fri 27 Oct 2017 11:19:35 > AM EDT. > > Error: > > Problem: conflicting requests > > - nothing provides libnfsidmap = 2.2.1-0.fc28 needed by > libnfsidmap-devel-1:2.2.1-0.fc28.x86_64 > > > > even though libnfsidmap-2.2.1-0 is installed. > > > > The problem is caused by the Requires: in the libnfsidmap-devel > subpackage > > > > %package -n libnfsidmap-devel > > Summary: Development files for the libnfsidmap library > > Group: Development/Libraries > > Requires: pkgconfig > > Requires: libnfsidmap = %{version}-%{release} > > ^^^^^^^^^^^ > > > > Now if I remove the '%{version}-%{release}' the package > > is installed/upgraded... but seems wrong to me > > the -devel should be tied to a particular version, right? > > > > Plus this was the way it was in the original libnfsidmap rpm. > The answer seems to be put a put a Provides: in the libnfsidmap subpackage > > Thanks for the help!!! > > No, not at all. You should change that requires to be: Requires: libnfsidmap = %{epoch}:%{version}-%{release}
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org