Bug 750345

Summary: katello/katello-configure need to have proper deps set before GA
Product: Red Hat Satellite Reporter: Corey Welton <cwelton>
Component: PackagingAssignee: Mike McCune <mmccune>
Status: CLOSED NOTABUG QA Contact: Katello QA List <katello-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.0.0CC: msuchy
Target Milestone: UnspecifiedKeywords: Patch, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-10 21:26:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Add requires to each spec. none

Description Corey Welton 2011-10-31 19:10:41 UTC 
Description of problem:

katello and katello-configure have no dependencies upon each other, meaning it would be very possible to install katello and install an older/newer release of katello-configure (or fail to update it later, etc.)  One would think that running a version of katello-configure against an incorrect version of a katello rpm could have dire consequences, particularly since there is (currently?) no rollback mechanism.


[root@se-rhelbox pulp]# yum deplist katello-configure 
Loaded plugins: product-id, rhnplugin, subscription-manager
Updating Red Hat repositories.
katello-devel                                                                                                                         | 1.3 kB     00:00     
Finding dependencies: 
package: katello-configure.noarch 0.1.7-1.git.29.b94a200.el6
  dependency: puppet >= 2.6.6
   provider: puppet.noarch 2.6.6-3.el6
  dependency: /usr/bin/ruby
   provider: ruby.x86_64 1.8.7.299-5.el6_0.1
   provider: ruby.x86_64 1.8.7.299-4.el6
   provider: ruby.x86_64 1.8.7.352-3.el6
   provider: ruby.x86_64 1.8.7.299-7.el6
   provider: ruby.x86_64 1.8.7.299-7.el6_1.1
package: katello-configure.noarch 0.1.7-1.git.29.b94a200.el6
  dependency: puppet >= 2.6.6
   provider: puppet.noarch 2.6.6-3.el6
  dependency: /usr/bin/ruby
   provider: ruby.x86_64 1.8.7.299-5.el6_0.1
   provider: ruby.x86_64 1.8.7.299-4.el6
   provider: ruby.x86_64 1.8.7.352-3.el6
   provider: ruby.x86_64 1.8.7.299-7.el6
   provider: ruby.x86_64 1.8.7.299-7.el6_1.1



Other notes:

We should be making a list of similar such deps that need to be resolved. Obviously the rubygems are a different thing entirely, but the federated pieces -- especially those katello-specific -- need to take deps into some consideration.
Comment 1 Mike McCune 2011-11-02 15:34:55 UTC 
handing to cliff
Comment 2 Clifford Perry 2011-11-07 19:54:40 UTC 
Isn't this what katello-all package is for though? 

It feels like busy work. I would assume any future update/upgrade process would be to do a 'yum update -y katello-all' to newer/newest packages and then run some sort of upgrade script akin to katello-configure. 

Today katello-configure is used one time only for clean installations. Once installed you would not run 'yum update katello*' followed by a 'katello-configure' script. Once we GA, if there is need for katello to have a specific requirement/version of katello-configure, then we would add that dep during errata cycle work. 

This bug I feel should be on back burner until we know what an update/upgrade process is going to look like. Does it extend out katello-configure, or is it its own set of scripts/tooling independent of clean installs. 

Cliff
Comment 4 Clifford Perry 2012-01-24 20:23:34 UTC 
Created attachment 557308 [details]
Add requires to each spec.
Comment 6 Miroslav Suchý 2012-08-22 08:27:42 UTC 
Package "katello" should not require package "katello-configure".

I would suppose that our upgrade script should include step:
  yum upgrade
because:
  yum update -y katello-all
never do the full update (include thirparty gems), which would stay on their minimal required version, although newer and better version is available.

And in requirements should be always the minimal dependency. Not the highest available.

I propose to close this BZ.