Bug 1254640 - /usr/sbin/sserver is provided both by krb5-server and krb5-devel
/usr/sbin/sserver is provided both by krb5-server and krb5-devel
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5 (Show other bugs)
7.1
Unspecified Unspecified
low Severity unspecified
: rc
: ---
Assigned To: Robbie Harwood
Patrik Kis
:
Depends On: 1250228
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-18 10:40 EDT by Jan Pazdziora
Modified: 2017-08-01 13:58 EDT (History)
8 users (show)

See Also:
Fixed In Version: krb5-1.15.1-3.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1250228
Environment:
Last Closed: 2017-08-01 13:58:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2015-08-18 10:40:29 EDT
+++ This bug was initially created as a clone of Bug #1250228 +++

Description of problem:

The /usr/sbin/sserver and /usr/bin/sclient are provided by both krb5-server and krb5-devel. That seems very wrong.

Version-Release number of selected component (if applicable):

krb5-devel-1.13.2-5.fc22.x86_64
krb5-server-1.13.2-5.fc22.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. rpm -qf /usr/sbin/sserver
2. rpm -qf /usr/bin/sclient

Actual results:

krb5-devel-1.13.2-5.fc22.x86_64
krb5-server-1.13.2-5.fc22.x86_64

Expected results:

Just krb5-server provides stuff from /usr/sbin/ and /usr/bin.

Additional info:
Comment 1 Jan Pazdziora 2015-08-18 10:41:31 EDT
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
Comment 3 Roland Mainz 2015-08-18 13:33:04 EDT
Taking bug myself ...
Comment 4 Roland Mainz 2015-08-18 13:37:41 EDT
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) ...
Comment 5 Jan Pazdziora 2015-08-18 15:05:47 EDT
(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?
Comment 6 Patrik Kis 2015-08-19 04:40:58 EDT
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.
Comment 7 Jan Pazdziora 2015-08-19 05:31:18 EDT
(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.
Comment 8 Patrik Kis 2015-08-19 08:40:00 EDT
(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.
Comment 15 Jan Pazdziora 2015-08-27 07:21:33 EDT
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.
Comment 16 Nalin Dahyabhai 2015-08-27 11:04:30 EDT
(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?
Comment 17 Jan Pazdziora 2015-08-27 11:14:26 EDT
(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.
Comment 18 Nalin Dahyabhai 2015-08-27 11:27:25 EDT
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
Comment 19 Jan Pazdziora 2015-08-27 11:45:51 EDT
(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.
Comment 21 Robbie Harwood 2015-09-10 14:27:32 EDT
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.
Comment 26 errata-xmlrpc 2017-08-01 13:58:41 EDT
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

Note You need to log in before you can comment on or make changes to this bug.