Why does package resource not understand source packages?

Chef Infra (archive)
1

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

2

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 jaypipes@gmail.com 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:

Paste #29738 | LodgeIt!

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

3

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 aj@junglist.gen.nz 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 jaypipes@gmail.com 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:

Paste #29738 | LodgeIt!

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

4

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 <aj@junglist.gen.nz
mailto:aj@junglist.gen.nz> 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 <jaypipes@gmail.com
<mailto:jaypipes@gmail.com>> 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
5

fair enough ... but AFAICT, apt doesn't really handle the "source"
attribute, while dpkg does...

I guess I care less of the exact implementation details, but the end result

  • if you use a source attribute, you probably don't want to use apt. So, to
    stay DRY, it'd be nice if the presence of "source" would trigger chef to
    use dpkg rather than apt.

On Tue, Jan 22, 2013 at 10:26 PM, Dan Razzell danr@activestate.com 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 aj@junglist.gen.nzwrote:

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 jaypipes@gmail.com 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:

Paste #29738 | LodgeIt!

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

6

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 danr@activestate.com 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 aj@junglist.gen.nz 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 jaypipes@gmail.com 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:

Paste #29738 | LodgeIt!

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

7

Apt does not. But yum does. Can't think of a clean solution though. I use
tend to use dpkg_package while specifying source

On Jan 22, 2013 7:32 PM, "andi abes" andi.abes@gmail.com wrote:

fair enough ... but AFAICT, apt doesn't really handle the "source"
attribute, while dpkg does...

I guess I care less of the exact implementation details, but the end
result - if you use a source attribute, you probably don't want to use apt.
So, to stay DRY, it'd be nice if the presence of "source" would trigger
chef to use dpkg rather than apt.

On Tue, Jan 22, 2013 at 10:26 PM, Dan Razzell danr@activestate.com
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 aj@junglist.gen.nz
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 jaypipes@gmail.com 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:

Paste #29738 | LodgeIt!

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

8

On 1/22/13 5:33 PM, "Jay Pipes" jaypipes@gmail.com wrote:

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:

Paste #29738 | LodgeIt!

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...

No mas. The way Chef works is to map a default provider to the platform
you are on, not to any other magic (like file extension.) You can, as you
correctly surmised, use dpkg_package, or specify the provider with the
provider meta-param.

Best,
Adam

9

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)"
lusis.org+chef-list@gmail.com 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 danr@activestate.com
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 aj@junglist.gen.nz
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 jaypipes@gmail.com 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:

Paste #29738 | LodgeIt!

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

10

On Tue, Jan 22, 2013 at 11:02 PM, Adam Jacob adam@opscode.com wrote:

On 1/22/13 5:33 PM, "Jay Pipes" jaypipes@gmail.com wrote:

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:

Paste #29738 | LodgeIt!

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...

No mas. The way Chef works is to map a default provider to the platform
you are on, not to any other magic (like file extension.) You can, as you
correctly surmised, use dpkg_package, or specify the provider with the
provider meta-param.

Thing is that this would make the recipe platform specific. As folks
pointed out, on other the same provider can handle both local files and
repos.

It would be really nice if there's a way to, e.g. provide the installation
source (e.g. from environment / platform attribute) and have chef magic
figure out how to manifest that on the node.

e.g [1]. but rather than just package name, pass in file, and have it do
"The Right Thing" on different platforms. I'm potentially extending Jay's
original request..

[1]
https://github.com/att-cloud/cookbook-glance/blob/master/attributes/default.rb#L74

Best,
Adam

11

On Tue, Jan 22, 2013 at 11:02 PM, Adam Jacob adam@opscode.com wrote:

On 1/22/13 5:33 PM, "Jay Pipes" jaypipes@gmail.com wrote:

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:

Paste #29738 | LodgeIt!

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...

No mas. The way Chef works is to map a default provider to the platform
you are on, not to any other magic (like file extension.) You can, as you
correctly surmised, use dpkg_package, or specify the provider with the
provider meta-param.

Thing is that this would make the recipe platform specific. As folks pointed out, on other the same provider can handle both local files and repos.
You could pass both, source and provider attributes filled from a data bag to the package provider. That would keep your cookbook platform independent.
Or you hide a if node['platform'] == 'ubuntu' else block inside a definition. The definition could then either create a generic package resource for everything not ubuntu and a dpkg_resource on ubuntu.

  • Matthias
12

On 01/22/2013 10:32 PM, andi abes wrote:

fair enough ... but AFAICT, apt doesn't really handle the "source"
attribute, while dpkg does...

I guess I care less of the exact implementation details, but the end
result - if you use a source attribute, you probably don't want to use
apt. So, to stay DRY, it'd be nice if the presence of "source" would
trigger chef to use dpkg rather than apt.

Exactly my point, Andi. Thanks!
-jay

On Tue, Jan 22, 2013 at 10:26 PM, Dan Razzell <danr@activestate.com
mailto:danr@activestate.com> 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
<aj@junglist.gen.nz <mailto:aj@junglist.gen.nz>> 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 <jaypipes@gmail.com
    <mailto:jaypipes@gmail.com>> 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