FAQ
Hi, I've defined this module:

package {['build-essential', "linux-headers-${kernelrelease}", 'dkms',
'linux-headers-server']:
ensure => installed,
}

and when the package linux-headers-server it's upgraded in the repositories
puppet tries to upgrade in client too. And as that package has a dependency
with latest kernel also upgrade it.

I'm defining ensure => installed, not ensure => latest

Anyone has experienced this, or similar, behaviour?
Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/06vr9dljjZkJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Sharuzzaman Ahmat Raslan at Apr 25, 2012 at 9:08 am
    Hi,

    linux-headers-server are metapackage. They always point to the latest real
    package, eg linux-headers-2.6.32-41-server

    That will cause puppet to always update the package to the latest version.

    To prevent that, always refer to specific package name, eg.
    linux-headers-2.6.32-41-server , not metapackage linux-headers-server


    2012/4/25 Juan José Presa Rodal <[email protected]>
    Hi, I've defined this module:

    package {['build-essential', "linux-headers-${kernelrelease}", 'dkms',
    'linux-headers-server']:
    ensure => installed,
    }

    and when the package linux-headers-server it's upgraded in the
    repositories puppet tries to upgrade in client too. And as that package has
    a dependency with latest kernel also upgrade it.

    I'm defining ensure => installed, not ensure => latest

    Anyone has experienced this, or similar, behaviour?
    Thanks in advance.

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To view this discussion on the web visit
    https://groups.google.com/d/msg/puppet-users/-/06vr9dljjZkJ.
    To post to this group, send email to [email protected].
    To unsubscribe from this group, send email to
    [email protected].
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.


    --
    Sharuzzaman Ahmat Raslan

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to [email protected].
    To unsubscribe from this group, send email to [email protected].
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Juan José Presa Rodal at Apr 25, 2012 at 9:59 am
    Ok, but then this response is unconsistent:

    # puppet resource package linux-headers-server

    package { 'linux-headers-server':
    ensure => '2.6.32.41.48',
    }

    I thought that if ensure property wasn't "absent", package provider make
    nothing...

    Would not be that way more consistent behaviour?


    El miércoles, 25 de abril de 2012 11:08:26 UTC+2, Sharuzzaman Ahmat Raslan
    escribió:
    Hi,

    linux-headers-server are metapackage. They always point to the latest real
    package, eg linux-headers-2.6.32-41-server

    That will cause puppet to always update the package to the latest version.

    To prevent that, always refer to specific package name, eg.
    linux-headers-2.6.32-41-server , not metapackage linux-headers-server


    2012/4/25 Juan José Presa Rodal <[email protected]>
    Hi, I've defined this module:

    package {['build-essential', "linux-headers-${kernelrelease}", 'dkms',
    'linux-headers-server']:
    ensure => installed,
    }

    and when the package linux-headers-server it's upgraded in the
    repositories puppet tries to upgrade in client too. And as that package has
    a dependency with latest kernel also upgrade it.

    I'm defining ensure => installed, not ensure => latest

    Anyone has experienced this, or similar, behaviour?
    Thanks in advance.

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To view this discussion on the web visit
    https://groups.google.com/d/msg/puppet-users/-/06vr9dljjZkJ.
    To post to this group, send email to [email protected].
    To unsubscribe from this group, send email to
    [email protected].
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.


    --
    Sharuzzaman Ahmat Raslan
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/GVGC_R8XjHEJ.
    To post to this group, send email to [email protected].
    To unsubscribe from this group, send email to [email protected].
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Apr 25, 2012 at 2:30 pm

    On Apr 25, 4:59 am, Juan José Presa Rodal wrote:
    Ok, but then this response is unconsistent:

    # puppet resource package linux-headers-server

    package { 'linux-headers-server':
    ensure => '2.6.32.41.48',

    }

    I thought that if ensure property wasn't "absent", package provider make
    nothing...

    Much depends on the package versioning. Given that declaration, the
    agent will do nothing in the event that version 2.6.32.41.48 of a
    package named 'linux-headers-server' is installed. If no package with
    that name is installed, then Puppet will attempt to install the
    specified version of it. If a different version is installed, then
    Puppet will attempt to up/downgrade to the specified version.

    I'm not very clear on Ubuntu package naming and versioning involved
    here, but I'm suspicious that you may be mixing the two. Is 'linux-
    headers-server' actually the *name* of the package you want, or is it
    perhaps the name and version? (That is, could it refer to version
    "server" of the "linux-headers" package?) The latter would constitute
    an error in your manifest, but Puppet is not necessarily able to
    recognize that.

    You could consider running the agent in debug mode toget the actual
    commands Puppet is issuing recorded in the client-side log. Look not
    only at the package installation command, but also at the preceding
    package query command. You would want also to refer to the
    appropriate repository metadata for the package(s) you're looking at.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to [email protected].
    To unsubscribe from this group, send email to [email protected].
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 25, '12 at 8:53a
activeApr 25, '12 at 2:30p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2023 Grokbase