Bug 750345 - katello/katello-configure need to have proper deps set before GA
Summary: katello/katello-configure need to have proper deps set before GA
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Packaging
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
high vote
Target Milestone: Unspecified
Assignee: Mike McCune
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-31 19:10 UTC by Corey Welton
Modified: 2018-08-30 21:57 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-10 21:26:36 UTC
Target Upstream Version:


Attachments (Terms of Use)
Add requires to each spec. (853 bytes, patch)
2012-01-24 20:23 UTC, Clifford Perry
no flags Details | Diff

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.


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