Packaging Question

[Steve Dickson]

Hello,

In an upcoming release the libnfsdimap library
will be rolled into the nfs-utils package.
Meaning nfs-utils will be install libnfsidmap 
instead of the libnfsidmap package. 

The libnfsidmap name will stay the same
so I'm hoping there will not be any problems. 
Just the owner of the library will change.

Questions:

1) What do I do with the old libnfsidmap package
   since it will no longer be updated.

2) How do I notify the packages that are dependent
   on the libnfsidmap package to change their dependency
   to nfs-utils

3) Will this cause any build problems now that nfs-utils
   will be installing the new library?

4) What am I missing? 

tia,

steved.

[William Moreno]

*William Moreno Reyes*
Colaborador Proyecto Fedora | Nicaragua
IRC:  williamjmorenor Canales: #fedora-latam ; #fedora-ni
https://fedoraproject.org/wiki/User:Williamjmorenor

2017-10-26 7:57 GMT-06:00 Steve Dickson <SteveD(a)redhat.com&gt;:

>  Hello,
>
>  In an upcoming release the libnfsdimap library
>  will be rolled into the nfs-utils package.
>  Meaning nfs-utils will be install libnfsidmap
>  instead of the libnfsidmap package.
>
>  The libnfsidmap name will stay the same
>  so I'm hoping there will not be any problems.
>  Just the owner of the library will change.
>
>  Questions:
>
>  1) What do I do with the old libnfsidmap package
>     since it will no longer be updated.
>
>  
Sound likes you can retire the package.


>  2) How do I notify the packages that are dependent
>     on the libnfsidmap package to change their dependency
>     to nfs-utils
>
>  
You can include in the nfs-utils spec something like this:

Provides: libnfsidmap = %{version}-%{release}
Obsoletes: libnfsidmap < %{version}-%{release}

https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_...



>  3) Will this cause any build problems now that nfs-utils
>     will be installing the new library?
>
>  4) What am I missing?
>
>  tia,
>
>  steved.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 26, 2017 at 08:09:00AM -0600, William Moreno wrote:
>  *William Moreno Reyes*
>  Colaborador Proyecto Fedora | Nicaragua
>  IRC:  williamjmorenor Canales: #fedora-latam ; #fedora-ni
>  https://fedoraproject.org/wiki/User:Williamjmorenor
>  
>  2017-10-26 7:57 GMT-06:00 Steve Dickson <SteveD(a)redhat.com&gt;:
>  
>  > Hello,
>  >
>  > In an upcoming release the libnfsdimap library
>  > will be rolled into the nfs-utils package.
>  > Meaning nfs-utils will be install libnfsidmap
>  > instead of the libnfsidmap package.
>  >
>  > The libnfsidmap name will stay the same
>  > so I'm hoping there will not be any problems.
>  > Just the owner of the library will change.
>  >
>  > Questions:
>  >
>  > 1) What do I do with the old libnfsidmap package
>  >    since it will no longer be updated.
>  >
>  >
>  Sound likes you can retire the package.
>  
>  
>  > 2) How do I notify the packages that are dependent
>  >    on the libnfsidmap package to change their dependency
>  >    to nfs-utils
>  >
>  >
>  You can include in the nfs-utils spec something like this:
>  
>  Provides: libnfsidmap = %{version}-%{release}
>  Obsoletes: libnfsidmap < %{version}-%{release} 
It is also important to provide the archful name, so in addition to the above:

Provides: libnfsidmap%{_isa} = %{version}-%{release}

libnfsidmap currently Provides nfs-utils-lib, so might want to copy
that over too. If it's very old, you can drop it. Just make sure
nothing in the distro still uses it.

Also, libnfsidmap-devel must be similarly obsoleted. It Provides:
libnfsidmap-devel
libnfsidmap-devel%{_isa}
pkgconfig(libnfsidmap)

Zbyszek

> https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_...
>  
>  
>  
>  > 3) Will this cause any build problems now that nfs-utils
>  >    will be installing the new library?
>  >
>  > 4) What am I missing?
>  >
>  > tia,
>  >
>  > steved.
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > 
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Stephen Gallagher]

On Thu, Oct 26, 2017 at 10:00 AM Steve Dickson <SteveD(a)redhat.com&gt; wrote:

>  Hello,
>
>  In an upcoming release the libnfsdimap library
>  will be rolled into the nfs-utils package.
>  Meaning nfs-utils will be install libnfsidmap
>  instead of the libnfsidmap package.
>
>  The libnfsidmap name will stay the same
>  so I'm hoping there will not be any problems.
>  Just the owner of the library will change.
>
>  
Useful general page:
https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitt...


>  Questions:
>
>  1) What do I do with the old libnfsidmap package
>     since it will no longer be updated.
>
>  
You will want to retire this SRPM. Follow
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life


>  2) How do I notify the packages that are dependent
>     on the libnfsidmap package to change their dependency
>     to nfs-utils
>
>  
Well, you don't need to do that. You can have nfs-utils do a virtual
Provides: on libnfsidmap. Also, if they are using automatic requires, those
should Just Work, since they are now comig from a new package.

You will want to make sure to add `Obsoletes: libnfsidmap <=
<last_released_version>` to nfs-utils.


>  3) Will this cause any build problems now that nfs-utils
>     will be installing the new library?
>
>  
Nope.


>  4) What am I missing?
>
>

[Steve Dickson]

Hello,

On 10/26/2017 09:57 AM, Steve Dickson wrote:
>  Hello,
>  
>  In an upcoming release the libnfsdimap library
>  will be rolled into the nfs-utils package.
>  Meaning nfs-utils will be install libnfsidmap 
>  instead of the libnfsidmap package. 
>  
>  The libnfsidmap name will stay the same
>  so I'm hoping there will not be any problems. 
>  Just the owner of the library will change.
>  
>  Questions:
>  
>  1) What do I do with the old libnfsidmap package
>     since it will no longer be updated.
>  
>  2) How do I notify the packages that are dependent
>     on the libnfsidmap package to change their dependency
>     to nfs-utils
>  
>  3) Will this cause any build problems now that nfs-utils
>     will be installing the new library?
>  
>  4) What am I missing?  
First of all... thanks for all the input!!! Its definitely appreciated!!

Here is what has been added to the nfs-utils spec file.

Provides: libnfsidmap%{_isa} = %{epoch}:%{version}-%{release}
Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release}

Obsoletes: libnfsidmap < %{version}-%{release}
Obsoletes: libnfsidmap-devel < %{version}-%{release}

%package -n libnfsidmap
Summary: NFSv4 User and Group ID Mapping Library
Obsoletes: nfs-utils-lib
Group: System Environment/Libraries
BuildRoot: %{_tmppath}/%{name}-%{version}-root
BuildRequires: pkgconfig, openldap-devel
BuildRequires: automake, libtool
Requires(postun): /sbin/ldconfig
Requires(pre): /sbin/ldconfig
Requires: openldap

%description -n libnfsidmap
Library that handles mapping between names and ids for NFSv4.

%package -n libnfsidmap-devel
Summary: Development files for the libnfsidmap library
Group: Development/Libraries
Requires: libnfsidmap = %{version}-%{release}
Requires: pkgconfig

%description -n libnfsidmap-devel
This package includes header files and libraries necessary for
developing programs which use the libnfsidmap library.

A couple things are still not right
1) when I do the update of nfs-utils, libnfsidmap and libnfsidmap-devel
   nfs-utils and libnfsidmap are installed correctly but the
   libnfsidmap-devel is "replaced" by nfs-utils:

Upgrading:
 libnfsidmap       x86_64       1:2.2.1-0.fc28         @commandline       102 k
 nfs-utils         x86_64       1:2.2.1-0.fc28         @commandline       413 k
     replacing  libnfsidmap-devel.x86_64 0.27-3.fc27

   which basically ends up remove it.

2) 'dnf downgrade nfs-utils' I'm assuming should also downgrade libnfsidmap
    as well... but only nfs-utils is downgraded. BUT... if a 
    'dnf downgrade libnfsidmap' is done, both libnfsidmap and nfs-utils are
downgraded.

3) there no libnfsidmap-debuginfo rpm being built. 

any ideas?? 

tia,

steved.

[Hedayat Vatankhah]

Hi,

/*Steve Dickson*/ wrote on Thu, 26 Oct 2017 14:10:49 -0400:
>  Hello,
>
>  On 10/26/2017 09:57 AM, Steve Dickson wrote:
> > Hello,
> >
> > In an upcoming release the libnfsdimap library
> > will be rolled into the nfs-utils package.
> > Meaning nfs-utils will be install libnfsidmap
> > instead of the libnfsidmap package.
> >
> > The libnfsidmap name will stay the same
> > so I'm hoping there will not be any problems.
> > Just the owner of the library will change.
> >
> > Questions:
> >
> > 1) What do I do with the old libnfsidmap package
> >     since it will no longer be updated.
> >
> > 2) How do I notify the packages that are dependent
> >     on the libnfsidmap package to change their dependency
> >     to nfs-utils
> >
> > 3) Will this cause any build problems now that nfs-utils
> >     will be installing the new library?
> >
> > 4) What am I missing?
>  First of all... thanks for all the input!!! Its definitely appreciated!!
>
>  Here is what has been added to the nfs-utils spec file.
>
>  Provides: libnfsidmap%{_isa} = %{epoch}:%{version}-%{release}
>  Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release}
>
>  Obsoletes: libnfsidmap < %{version}-%{release}
>  Obsoletes: libnfsidmap-devel < %{version}-%{release} 
As you are actually
providing libnfsidmap & libnfsidmap-devel RPM 
packages, I think there is no need for the above. They were needed if 
you didn't put libnfsidmap in a separate RPM.
In your case, you are actually providing the same RPM packages, just 
from a different SRPM. So in the RPM repository, almost nothing is 
changed (except the name of SRPM which has produced those RPM packages, 
which has no effect on dependency resolution).


>  %package -n libnfsidmap
>  Summary: NFSv4 User and Group ID Mapping Library
>  Obsoletes: nfs-utils-lib
>  Group: System Environment/Libraries
>  BuildRoot: %{_tmppath}/%{name}-%{version}-root
>  BuildRequires: pkgconfig, openldap-devel
>  BuildRequires: automake, libtool
>  Requires(postun): /sbin/ldconfig
>  Requires(pre): /sbin/ldconfig
>  Requires: openldap
>
>  %description -n libnfsidmap
>  Library that handles mapping between names and ids for NFSv4.
>
>  %package -n libnfsidmap-devel
>  Summary: Development files for the libnfsidmap library
>  Group: Development/Libraries
>  Requires: libnfsidmap = %{version}-%{release}
>  Requires: pkgconfig
>
>  %description -n libnfsidmap-devel
>  This package includes header files and libraries necessary for
>  developing programs which use the libnfsidmap library.
>
>  A couple things are still not right
>  1) when I do the update of nfs-utils, libnfsidmap and libnfsidmap-devel
>      nfs-utils and libnfsidmap are installed correctly but the
>      libnfsidmap-devel is "replaced" by nfs-utils:
>
>  Upgrading:
>    libnfsidmap       x86_64       1:2.2.1-0.fc28         @commandline       102 k
>    nfs-utils         x86_64       1:2.2.1-0.fc28         @commandline       413 k
>        replacing  libnfsidmap-devel.x86_64 0.27-3.fc27
>
>      which basically ends up remove it. 
Because you've said that nfs-utils
package provides libnfsidmap-devel 
too. Actually, I would expect it to also remove libnfsidmap!

Regards,
Hedayat


>  2) 'dnf downgrade nfs-utils' I'm assuming should also downgrade libnfsidmap
>       as well... but only nfs-utils is downgraded. BUT... if a
>       'dnf downgrade libnfsidmap' is done, both libnfsidmap and nfs-utils are
> downgraded.
>
>  3) there no libnfsidmap-debuginfo rpm being built.
>
>  any ideas??
>
>  tia,
>
>  steved.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

Hi,

That's probably due to the

Provides: libnfsidmap%{_isa} = %{epoch}:%{version}-%{release}
Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release}

(not the energy to actually check)

From:

https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitt...
(did I actually write this some years ago? I had forgotten about it)

>  Do I need to Provide my old package names?
>  Providing your old package names is not necessary to create working upgrade paths[1].
>  [1] Yes, we know rpmlint will ask for Provides. Use your common sense and do not follow
> rpmlint warnings blindly.  
Regards,

-- 
Nicolas Mailhot

[William Moreno]

*William Moreno Reyes*
Colaborador Proyecto Fedora | Nicaragua
IRC:  williamjmorenor Canales: #fedora-latam ; #fedora-ni
https://fedoraproject.org/wiki/User:Williamjmorenor

2017-10-26 12:10 GMT-06:00 Steve Dickson <SteveD(a)redhat.com&gt;:

>  Hello,
>
>  On 10/26/2017 09:57 AM, Steve Dickson wrote:
>  > Hello,
>  >
>  > In an upcoming release the libnfsdimap library
>  > will be rolled into the nfs-utils package.
>  > Meaning nfs-utils will be install libnfsidmap
>  > instead of the libnfsidmap package.
>  >
>  > The libnfsidmap name will stay the same
>  > so I'm hoping there will not be any problems.
>  > Just the owner of the library will change.
>  >
>  > Questions:
>  >
>  > 1) What do I do with the old libnfsidmap package
>  >    since it will no longer be updated.
>  >
>  > 2) How do I notify the packages that are dependent
>  >    on the libnfsidmap package to change their dependency
>  >    to nfs-utils
>  >
>  > 3) Will this cause any build problems now that nfs-utils
>  >    will be installing the new library?
>  >
>  > 4) What am I missing?
>
>  First of all... thanks for all the input!!! Its definitely appreciated!!
>
>  Here is what has been added to the nfs-utils spec file.
>
>  Provides: libnfsidmap%{_isa} = %{epoch}:%{version}-%{release}
>  Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release}
>
>  Obsoletes: libnfsidmap < %{version}-%{release}
>  Obsoletes: libnfsidmap-devel < %{version}-%{release}
>
>  %package -n libnfsidmap
>  Summary: NFSv4 User and Group ID Mapping Library
>  Obsoletes: nfs-utils-lib
>  Group: System Environment/Libraries
>  BuildRoot: %{_tmppath}/%{name}-%{version}-root
>  BuildRequires: pkgconfig, openldap-devel
>  BuildRequires: automake, libtool
>  Requires(postun): /sbin/ldconfig
>  Requires(pre): /sbin/ldconfig
>  Requires: openldap
>
>  %description -n libnfsidmap
>  Library that handles mapping between names and ids for NFSv4.
>
>  %package -n libnfsidmap-devel
>  Summary: Development files for the libnfsidmap library
>  Group: Development/Libraries
>  Requires: libnfsidmap = %{version}-%{release}
>  Requires: pkgconfig
>
>  %description -n libnfsidmap-devel
>  This package includes header files and libraries necessary for
>  developing programs which use the libnfsidmap library.
>
>  A couple things are still not right
>  1) when I do the update of nfs-utils, libnfsidmap and libnfsidmap-devel
>     nfs-utils and libnfsidmap are installed correctly but the
>     libnfsidmap-devel is "replaced" by nfs-utils:
>
>  Upgrading:
>   libnfsidmap       x86_64       1:2.2.1-0.fc28         @commandline
>   102 k
>   nfs-utils         x86_64       1:2.2.1-0.fc28         @commandline
>   413 k
>       replacing  libnfsidmap-devel.x86_64 0.27-3.fc27
>
>     which basically ends up remove it.
>
>  Because the main package provides it: 
Provides: libnfsidmap-devel%{_isa} =
%{epoch}:%{version}-%{release}

Move this line under

%package -n libnfsidmap-devel

And you should get a clean update path

[Kevin Kofler]

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.

        Kevin Kofler

[Stephen Gallagher]

On Thu, Oct 26, 2017 at 9:12 PM Kevin Kofler <kevin.kofler(a)chello.at&gt; 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.
>
>  
One more caveat: make sure that the ENVR (epoch, name, version and release)
of the new libnfsidmap package sorts higher than that of the former
standalone package, or else it won't act as a replacement.

[Steve Dickson]

On 10/26/2017 09:40 PM, Stephen Gallagher wrote:
>  
>  
>  On Thu, Oct 26, 2017 at 9:12 PM Kevin Kofler <kevin.kofler(a)chello.at
> <mailto:[e-mail]>> 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.
>  
>  
>  
>  One more caveat: make sure that the ENVR (epoch, name, version and release) of the new
> libnfsidmap package sorts higher than that of the former standalone package, or else it
> won't act as a replacement. 
It will be... significantly.... Thanks!

steved.

[Steve Dickson]

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.

# dnf --best --allowerasing update /tmp/*rpm
Last metadata expiration check: 0:35:42 ago on Fri 27 Oct 2017 10:04:58 AM EDT.
Dependencies resolved.
================================================================================
 Package                 Arch       Version              Repository        Size
================================================================================
Upgrading:
 libnfsidmap             x86_64     1:2.2.1-0.fc28       @commandline     102 k
 nfs-utils               x86_64     1:2.2.1-0.fc28       @commandline     413 k
 nfs-utils-debuginfo     x86_64     1:2.2.1-0.fc28       @commandline     986 k
Removing:
 libnfsidmap-devel       x86_64     0.27-1.fc26          @fedora          3.3 k

Transaction Summary
================================================================================
Upgrade  3 Packages
Remove   1 Package

Total size: 1.5 M
Is this ok [y/N]: 

Which is confusing... 

Note the '--best --allowerasing' is needed for the libnfsidmap to be upgraded
(which I don't think is a big deal)

tia,

steved.

[Stephen Gallagher]

On Fri, Oct 27, 2017 at 10:55 AM Steve Dickson <SteveD(a)redhat.com&gt; 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? 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.

[Steve Dickson]

Hello,

On 10/27/2017 11:11 AM, Stephen Gallagher wrote:
>  
>  
>  On Fri, Oct 27, 2017 at 10:55 AM Steve Dickson <SteveD(a)redhat.com
> <mailto:[e-mail]>> 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.

tia,

steved.

[Kevin Kofler]

Steve Dickson wrote:
>  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 versioned dependency must include the Epoch (which is 1), i.e.:
Requires: libnfsidmap = %{epoch}:%{version}-%{release}

Note that subpackages inherit the Epoch from the main package unless you 
explicitly set Epoch: 0 in them (and you will probably not make rel-eng 
happy if you set that now after you already pushed the packages with Epoch 1 
into Rawhide, there was unfortunately a FESCo decision that EVRs (Epoch-
Version-Release versions) should never go backwards in Rawhide).

        Kevin Kofler

[Mattias Ellert]

fre 2017-10-27 klockan 11:47 -0400 skrev Steve Dickson:
>  
>  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.
>  
>  tia,
>  
>  steved. 
Your package has epoch defined, so you need to use it when declaring
versioned dependencies between binary packages. 2.2.1-0 is not the same
as 1:2.2.1-0. (And you should use _isa here:

%package -n libnfsidmap-devel
Requires: libnfsidmap%{?_isa} = %{epoch}:%{version}-%{release}

	Mattias

[Steve Dickson]

On 10/27/2017 12:17 PM, Mattias Ellert wrote:
>  fre 2017-10-27 klockan 11:47 -0400 skrev Steve Dickson:
> >
> > 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.
> >
> > tia,
> >
> > steved.
>  
>  Your package has epoch defined, so you need to use it when declaring
>  versioned dependencies between binary packages. 2.2.1-0 is not the same
>  as 1:2.2.1-0. (And you should use _isa here:
>  
>  %package -n libnfsidmap-devel
>  Requires: libnfsidmap%{?_isa} = %{epoch}:%{version}-%{release} 
Yup that did the
trick... This is what I ended up with
(No changes to the nfs-utils Requires:, Provides: or Obsoletes:)

%package -n libnfsidmap
Summary: NFSv4 User and Group ID Mapping Library
Provides: libnfsidmap%{?_isa} = %{epoch}:%{version}-%{release}
License: BSD
Group: System Environment/Libraries
BuildRequires: pkgconfig, openldap-devel
BuildRequires: automake, libtool
Requires(postun): /sbin/ldconfig
Requires(pre): /sbin/ldconfig
Requires: openldap


%package -n libnfsidmap-devel
Summary: Development files for the libnfsidmap library
Group: Development/Libraries
Requires: libnfsidmap%{?_isa} = %{epoch}:%{version}-%{release}
Requires: pkgconfig

Final question... hopefully :-)

Both packages share the same '%{epoch}:%{version}-%{release}'
So when I fix bug in the nfs-utils code that does
not effect the libnfsidmap code, the %{release} number
on libnfsidmap package will still go up. Vice versa
with the lib code and the nfs-utils %{release}

Question: Update time... I'm assuming that I should just
go ahead update both packages whether they are needed or
not... (assuming the update system will figure that out).

Or should I keep separate '%{version}-%{release}' 
for each package??

Again... Thank you very much for all the guidance!

steved.

[Stephen Gallagher]

>  Question: Update time... I'm assuming that I should just
>  go ahead update both packages whether they are needed or
>  not... (assuming the update system will figure that out).
>
>  Or should I keep separate '%{version}-%{release}'
>  for each package??
>
>  Again... Thank you very much for all the guidance!
>
>  
Keep them in sync. It's safer (so you don't forget to update one when the
other requires a new feature from it).

The only really good reason to do otherwise would be something like a data
set for a videogame where you probably don't want to force people to
re-download hundreds of megs for every code change.

[Steve Dickson]

On 10/27/2017 01:17 PM, Stephen Gallagher wrote:
>  
>  
>      Question: Update time... I'm assuming that I should just
>      go ahead update both packages whether they are needed or
>      not... (assuming the update system will figure that out).
>  
>      Or should I keep separate '%{version}-%{release}'
>      for each package??
>  
>      Again... Thank you very much for all the guidance!
>  
>  
>  Keep them in sync. It's safer (so you don't forget to update one when the other
> requires a new feature from it).
>  
>  The only really good reason to do otherwise would be something like a data set for a
> videogame where you probably don't want to force people to re-download hundreds of
> megs for every code change.  
Fair enough! 

Thanks!

steved.

[Steve Dickson]

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 <SteveD(a)redhat.com
> <mailto:[e-mail]>> 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!!! 

steved.

[Stephen Gallagher]

On Fri, Oct 27, 2017 at 12:25 PM Steve Dickson <SteveD(a)redhat.com&gt; 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 <SteveD(a)redhat.com
>  <mailto:[e-mail]>> 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}