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

Reply via email to