Bug 1254640

I see the same issue on RHEL 7.1:

# rpm -qf /usr/sbin/sserver
krb5-devel-1.12.2-14.el7.x86_64
krb5-server-1.12.2-14.el7.x86_64

Taking bug myself ...

Jan:
Why was this bug reported as "blocker" ?
I've talked to nalin on IRC and he says it's OK to deliver the files from both packages since its useful to do so (and RPM only allows this when the files are coming from the same build and are identical) ...

(In reply to Roland Mainz from comment #4)
> Jan:
> Why was this bug reported as "blocker" ?

Because I believe it's that time of the year that getting release ack requires blocker set. I might be wrong though.

> I've talked to nalin on IRC and he says it's OK to deliver the files from
> both packages since its useful to do so (and RPM only allows this when the
> files are coming from the same build and are identical) ...

https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages says:

  Specifically, -devel packages must be used to contain files which
  are intended solely for development or needed only at build-time.

Is that the case for /usr/sbin/sserver and /usr/bin/sclient? Why is it useful to pack those files in both subpackages?

Note, there are other test binaries delivered in krb5-devel package:

# rpm -ql krb5-server |grep bin
/usr/bin/sclient
/usr/sbin/_kadmind
/usr/sbin/_kpropd
/usr/sbin/kadmin.local
/usr/sbin/kadmind
/usr/sbin/kdb5_util
/usr/sbin/kprop
/usr/sbin/kpropd
/usr/sbin/kproplog
/usr/sbin/krb5kdc
/usr/sbin/sserver

but only sserver and scliet are present in krb5-server too. So just removal of sserver and sclient from the -server package is not a systematic change and we will get into a kind of inconsistent state as the other tools are principally the same (kind if test tools, to verify the basic functionality).
Therefore, if we are going to change this, it should be changed for all tools, having half of then in one subpackage and the rest in the other is not really a good packaging approach.

I personally fine with having all these tools in the -devel package.
Note, https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages also says this:

<quotation>
When in doubt as to whether a file belongs in the base package or in -devel, packagers should consider whether the file is necessary to be present for a user to use or execute the functionality in the base package properly, or if it is only necessary for development. If it is only necessary for development, it must go into a -devel package.
</quotation>

Therefore IMHO, if these binaries should be removed, they should be removed from -server to minimize the install footprint for users. I believe the -server package is installed more widely and on production systems, what users want to have "clean". Contrary, the -devel packages are installed on devel/test machines, where test tools may be handy and some "overhead" is not an issue.

(In reply to Patrik Kis from comment #6)
> Note, there are other test binaries delivered in krb5-devel package:
> 
> # rpm -ql krb5-server |grep bin
> /usr/bin/sclient
> /usr/sbin/_kadmind
> /usr/sbin/_kpropd
> /usr/sbin/kadmin.local
> /usr/sbin/kadmind
> /usr/sbin/kdb5_util
> /usr/sbin/kprop
> /usr/sbin/kpropd
> /usr/sbin/kproplog
> /usr/sbin/krb5kdc
> /usr/sbin/sserver

Actually, krb5-devel list is

# rpm -ql krb5-devel |grep bin
/usr/bin/gss-client
/usr/bin/krb5-config
/usr/bin/sclient
/usr/bin/sim_client
/usr/bin/uuclient
/usr/sbin/gss-server
/usr/sbin/sim_server
/usr/sbin/sserver
/usr/sbin/uuserver

> but only sserver and scliet are present in krb5-server too. So just removal
> of sserver and sclient from the -server package is not a systematic change
> and we will get into a kind of inconsistent state as the other tools are
> principally the same (kind if test tools, to verify the basic functionality).
> Therefore, if we are going to change this, it should be changed for all
> tools, having half of then in one subpackage and the rest in the other is
> not really a good packaging approach.

I don't really care which way the duplicity is resolved.

If the utilities are supposed to be used by end users (and there are man pages for for sserver and sclient, so it looks like they are), removing them from -devel seems reasonable. If they are only to be used for development and debugging, removing them from -server is probably preferable.

(In reply to Jan Pazdziora from comment #7)
> (In reply to Patrik Kis from comment #6)
> > Note, there are other test binaries delivered in krb5-devel package:
> > 
> > # rpm -ql krb5-server |grep bin
> > /usr/bin/sclient
> > /usr/sbin/_kadmind
> > /usr/sbin/_kpropd
> > /usr/sbin/kadmin.local
> > /usr/sbin/kadmind
> > /usr/sbin/kdb5_util
> > /usr/sbin/kprop
> > /usr/sbin/kpropd
> > /usr/sbin/kproplog
> > /usr/sbin/krb5kdc
> > /usr/sbin/sserver
> 
> Actually, krb5-devel list is
> 
> # rpm -ql krb5-devel |grep bin
> /usr/bin/gss-client
> /usr/bin/krb5-config
> /usr/bin/sclient
> /usr/bin/sim_client
> /usr/bin/uuclient
> /usr/sbin/gss-server
> /usr/sbin/sim_server
> /usr/sbin/sserver
> /usr/sbin/uuserver
> 
Upps, my bad!

> > but only sserver and scliet are present in krb5-server too. So just removal
> > of sserver and sclient from the -server package is not a systematic change
> > and we will get into a kind of inconsistent state as the other tools are
> > principally the same (kind if test tools, to verify the basic functionality).
> > Therefore, if we are going to change this, it should be changed for all
> > tools, having half of then in one subpackage and the rest in the other is
> > not really a good packaging approach.
> 
> I don't really care which way the duplicity is resolved.

Then I believe, it should all kept in -devel, to have all similar tools in the same package.

> 
> If the utilities are supposed to be used by end users (and there are man
> pages for for sserver and sclient, so it looks like they are), removing them
> from -devel seems reasonable. If they are only to be used for development
> and debugging, removing them from -server is probably preferable.

Yes, I agree. The problem probably is, that we are not able clearly define which party suppose to use these tools. Probably booth, in some circumstances.

Just because we can do weird things does not mean we should.

On my IdM installation, I run

   rpm -qa --qf '%{name}-devel\n' | xargs yum install -y

and installed 217 -devel packages (plus 53 dependencies). No other package creates duplicates (files owned by two packages) in /usr/bin or /usr/sbin, tested with

   rpm -qal | grep -E '^/usr/s?bin' | sort | uniq -d | while read -r f ; do if [ -f "$f" ] ; then echo "$f" ; fi ; done

This time it was me who lost hour or more investigating issue caused by this and workarounding it in tests. In the future it will be someone else.

(In reply to Jan Pazdziora from comment #15)
> This time it was me who lost hour or more investigating issue caused by this
> and workarounding it in tests. In the future it will be someone else.

To make sure we're all on the same page here, can you describe the issue you were investigating in more detail?

(In reply to Nalin Dahyabhai from comment #16)
> 
> To make sure we're all on the same page here, can you describe the issue you
> were investigating in more detail?

https://fedorahosted.org/freeipa/ticket/5180

When you happen to have those packages built from different sources, then they conflict.

Ah.  The copr FAQ recommends against duplicating NVRs with official repositories [1], and I personally don't relish the idea of having to ask for not only NVRs, but point of origin for particular packages and subpackages to be able to know what's in them, when troubleshooting things.

[1] https://fedorahosted.org/copr/wiki/UserDocs#HowcanItellyumtopreferCoprpackages

(In reply to Nalin Dahyabhai from comment #18)
> Ah.  The copr FAQ recommends against duplicating NVRs with official

Definitely.

But I'm merely end-use consumer here and so are the other users for which the FreeIPA 4.2 installations were potentially broken for two weeks just because krb5 packaging tries to be clever and does something which while might not be exactly forbidden (but see below) but which to me is definitely something we should avoid doing.

If this issue won't be fixed, so be it. I've received my share of WONTFIXes on my reports where I attempted to make life more predictable and more sane for others. I won't reopen.

I will however maintain my conviction that it's a bug because by having those files in krb5-server, the requirement of

  Specifically, -devel packages must be used to contain files which
  are intended solely for development or needed only at build-time.

is not met -- if they are in krb5-server, they are not solely for development or needed only at build-time, and in that case they have no business being in krb5-devel. Plus it's ugly.

Jan,

I agree that this would be nice to have, and my reading of the requirements concurs with yours.  However, your immediate issue has been resolved, so this is going to be deferred a bit unless it's breaking something else.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1891