Bug 459040
Summary: | ocs-kit packages name ambiguity | ||
---|---|---|---|
Product: | Red Hat HPC Solution | Reporter: | Rafael Garabato <rafael.f.garabato> |
Component: | ocs | Assignee: | OCS Support <ocs2> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 5.1 | CC: | jturner, keve.a.gabbert, mblack, ocs2, rafael.f.garabato, riek, rpacheco |
Target Milestone: | --- | Keywords: | Documentation |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-12-14 16:13:07 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Rafael Garabato
2008-08-13 21:17:03 UTC
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. http://rhn.redhat.com/errata/RHEA-2009-1667.html |