Red Hat Bugzilla – Bug 459040
ocs-kit packages name ambiguity
Last modified: 2009-12-14 11:13:07 EST
Description of problem:
In Red Hat HPC, users must install the Kusu Kits with yum(8)
before adding them to the cluster repository. For each Kit there
are two versions, one of them is named ocs-kit-* and the other
kit-*. For example, there is a kit-ganglia.noarch package and an
It should be clarified the ones that must be installed. Maybe changing the names, I am not sure. But the fact is that I made some errors due to this problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The packages named: ocs-kit-* are the package downloaders. These download the kit rpms and assemble the kit for use in the repository.
The packages named: kit-* are the kit rpm's. These contain the documentation, plugins and any database updates.
The Readme http://people.redhat.com/riek/HPC-Solution/ talks about what to do to add the kits on page 3. We are planning on providing a update to this document listing all of the kits that can be downloaded from RHN.
Does that solve your problem.
I now understand the difference. I mean, I made a mistake and learned from my mistake what was the difference.
The problem is with future "new" users of Red Hat HPC.
In order to look for the available kits, I had to use something like:
yum list | grep kit.
For instance, I for ntop the following packages appeared:
kit-ntop.noarch 3.3-9 installed
ocs-kit-ntop.noarch 1.0-2 installed
The documentation says correctly to install ocs-kit-* , however, the documentation does also say that it supports Red Hat 5.1 (so I assumed that it may not be accurate). So I, as an ignorant user, assumed that the packages name may also be obsolete. So as kit-ntop has a newer version that ocs-kit-ntop I decided to install the former.
Again, I won't have the same problem again, but I would like to prevent other users from having it also. An explanation in the documentation may be enough. Or maybe It would also be great if the selection of kits is automatized so that the user doesn't have to search the yum repositories.
Just take into account that it is very probable that someone that finds ocs-kit-ntop and kit-ntop won't see the difference, as the names aren't self explanatory.
(In reply to comment #2)
> In order to look for the available kits, I had to use something like:
> yum list | grep kit.
Just FYI (while I can't add anything of more substance), you can use wildcards in yum/rpm to achieve the same:
yum list "*kit*"
rpm -qa "*kit*"
You can use that to easily differentiate between kit- and ocs-kit- packages:
yum list "kit*"
yum list "ocs-kit*"
(Note: only one wildcard used)
I think you should focus on how to extend this to other users as well.
I learnt from my mistakes.
It is not a problem of lack of knowledge on yum. The problem are the names of the packages. ocs-kit-* and kit-* doesn't differenciate on the name. If I had to guess (assuming I am a new user) the difference would be that one belongs to ocs while the other doesn't. Now if I had kit-ntop and kit-ntop-installer, how much did it changed?
I hope that now it is more clear which is my concern.
who needs to make this name change, Platform or Red Hat? Let's get this BZ assigned to the right person.
Well, changing this requires a number of changes in the build-environment and code of the download. That will lead to a delay.
I agree it is sub-optimal, but is the problem big enough to justify this?
I agree, it is not big enough. But I think that if you don't want to have unnecessary customer requests it should be explained well in the documentation.
Ok, let's clarify this in the Readme.
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.