Apt provider still can't install packages from different default release

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 10.12.0
  • Fix Version/s: 10.14.0
  • Component/s: Chef Client
  • Labels:
    None

Description

This issue was first reported here:
http://tickets.opscode.com/browse/CHEF-1547

Unfortunately the fix was only applied to apt-cache command in check_package_state method.
For correctness it should also be applied to apt-get install in install_package method.

Without this, it's possible that the installation fails with certain release priority settings.

I'll provide a topic branch with the fix.

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. CHEF-1547 Apt provider can't install packages from different default release

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Miguel Cabeça added a comment -

Here is the topic branch:
https://github.com/cabeca/chef/tree/CHEF-3266

Here is the pull request
https://github.com/opscode/chef/pull/327

Best regards
Miguel Cabeça

Show
Miguel Cabeça added a comment - Here is the topic branch: https://github.com/cabeca/chef/tree/CHEF-3266 Here is the pull request https://github.com/opscode/chef/pull/327 Best regards Miguel Cabeça
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Thanks Miguel. When you attack a patch please resolve the ticket as fixed and we will review the submission. I've got it this time for you.

Show
Bryan McLellan [Opscode] added a comment - Thanks Miguel. When you attack a patch please resolve the ticket as fixed and we will review the submission. I've got it this time for you.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Reviewed and marked for merge.

default_release_options should return an empty string though if we don't have a release set, and we're not really sure why this code is checking provider.

Show
Bryan McLellan [Opscode] added a comment - Reviewed and marked for merge. default_release_options should return an empty string though if we don't have a release set, and we're not really sure why this code is checking provider.
Hide
Permalink
Miguel Cabeça added a comment -

For what I can understand from the existing code, this code is checking if the provider was explicitly set either using

package "foo" do
provider "Chef::Provider::Package::Apt"
default_release "wheezy"
end

or

apt_package "foo" do
default_release "wheezy"
end

because default_release is only defined in apt_package resource, it is an apt specific option.

If the check fails in default_release_options it will return nil, witch I think is appropriate (meaning there are no options).
The expand_options method defined in package provider will take care of string sanitization:

def expand_options(options)
options ? " #{options}" : ""
end

Show
Miguel Cabeça added a comment - For what I can understand from the existing code, this code is checking if the provider was explicitly set either using package "foo" do provider "Chef::Provider::Package::Apt" default_release "wheezy" end or apt_package "foo" do default_release "wheezy" end because default_release is only defined in apt_package resource, it is an apt specific option. If the check fails in default_release_options it will return nil, witch I think is appropriate (meaning there are no options). The expand_options method defined in package provider will take care of string sanitization: def expand_options(options) options ? " #{options}" : "" end
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Merged to master. Thanks Miguel!

Show
Bryan McLellan [Opscode] added a comment - Merged to master. Thanks Miguel!

People

  • Assignee:
    Unassigned
    Reporter:
    Miguel Cabeça
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: