[chef] Re: Re: Re: Re: Re: Why does package resource not understand source packages?


Chronological Thread 
  • From: Adam Jacob < >
  • To: " " < >, " " < >
  • Subject: [chef] Re: Re: Re: Re: Re: Why does package resource not understand source packages?
  • Date: Wed, 23 Jan 2013 04:04:20 +0000
  • Accept-language: en-US

Bingo. The problem under the hood here is one of side effects: there is no
consistent way for Chef to behave in the face of the huge number of
possible combinations. Be specific if you're deviating from the system
norm.

Adam 

On 1/22/13 7:32 PM, "John E. Vincent (lusis)"
< >
 wrote:

>Dan beat me too it.
>
>This is a case where chef can't possibly know what to do:
>
>- dpkg doesn't do dependency resolution
>- apt doesn't support installing local debs (unlike yum which has the
>localinstall option which still does dependency resolution)
>
>What is being asked for is for Chef to automagically switch to dpkg -i
>when the source is a .deb file. The problem is that this can leave
>your system in a horribly broken state (and it won't work anyway as
>dpkg -i will report as failed and thus the chef run will fail).
>
>AJ has the right of it. Specify the package provider if you're
>absolutely sure there are no other dependencies or you know for
>certain they're already installed (or just use the dpkg resource
>directly)
>
>On Tue, Jan 22, 2013 at 10:26 PM, Dan Razzell 
>< >
>wrote:
>> No, because, as with a number of packaging systems, the work is divided
>> between a low-level tool (dpkg, rpm, ...) that operates locally and
>>knows
>> nothing about dependencies, and a high-level tool (apt-get, yum, ...)
>>which
>> searches remote repos and knows about dependency resolution.
>>
>>
>> On 13-01-22 06:59 PM, andi abes wrote:
>>
>> hmm.. seems that dpkg < apt, and that apt doesn't actually handle the
>>source
>> attribute, while dpkg does.
>> Would it make sense to make dpkg the default package provider, but have
>>it
>> 'super' to apt if a source is not present?
>>
>>
>>
>> On Tue, Jan 22, 2013 at 9:25 PM, AJ Christensen 
>> < >
>>wrote:
>>>
>>> Jay,
>>>
>>> You can specify the 'provider' common attribute to any resource to
>>>control
>>> which provider the resource should use explicitly [0], e.g.;
>>>
>>> package "mypackage" do
>>>   source "/path/to/my/package.deb"
>>>   provider Chef::Provider::Package::Dpkg
>>> end
>>>
>>> It is my understanding that there is no platform mapped for the package
>>> resource that would cause any platform nor family to use the Dpkg
>>>provider
>>> by default -- generally I'd use them with the dpkg_package shortcut
>>> resource.
>>>
>>> Cheers,
>>>
>>> AJ
>>>
>>> [0] http://docs.opscode.com/resource_common_attributes.html
>>>
>>>
>>> On 23 January 2013 14:33, Jay Pipes 
>>> < >
>>>  wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm wondering why if I do this:
>>>>
>>>> package "mypackage" do
>>>>     source "/path/to/my/package.deb"
>>>> end
>>>>
>>>> that the package resource cannot figure out to use the Dpkg provider
>>>>to
>>>> install the package?
>>>>
>>>> Instead, I get an error about no version specified and no candidate
>>>> version available:
>>>>
>>>> http://paste.openstack.org/show/29738/
>>>>
>>>> If I change package to dpkg_package, it works correctly, but I was
>>>> hoping the generic package resource would handle this based on the
>>>>file
>>>> extension...
>>>>
>>>> Best,
>>>> -jay
>>>
>>>
>>
>





Archive powered by MHonArc 2.6.16.

§