On Monday, July 28, 2014 8:56:08 AM UTC-5, Dimitris Stafylarakis wrote:
thanks for your replies. My actual case is *run apt-get update before
upgrading a package*. So I have packages in my own repository and I'm
managing them through puppet on the production server. I want to be able to
set a specific version number and have puppet install the right version of
the package on the server.
@pete: actually I am using puppetlabs/apt. It works fine when a new
package is being installed but for some reason doesn't trigger an update
when upgrading a package (i.e., changing the version number in the ensure
@john: I understand that it's difficult to determine a priori which
resources will be refreshed, I was just asking in case someone found a
smart solution to this already. For now, I have to resolve to running
updates on every puppet run.
Let's be clear: there is no possible general solution -- smart or otherwise
-- for determining which resources will be modified in advance of
attempting to sync those resources. There are alternatives specific to
some particular resource types and to some individual resources, but the
general case requires unlimited ability to predict future events.
Turning now specifically to Package resources in an Apt environment, let's
think for a minute. What does 'apt-get update' do, and/or why do you need
to run it before updating Packages? Well, it updates the local machine's
cache of repository metadata, including especially the list of available
packages, which Apt does not do unless asked. If you want to ensure that a
given Package is at the latest version available from the repository, then
you need the update process to draw on up-to-date repository metadata. No
But wait! How do you know whether there's an update to an installed
package available at all? You need the current repository metadata for
that, too. How do you ensure your copy of the metadata is up to date?
Yes, 'apt-get update'. You cannot limit running 'apt-get update' to times
when there is a Package update to apply, because you need to run it before
you can determine whether there are any updates to apply at all.
With that said, if it were ok for machines to lag a bit behind repository
updates, then you could maybe apply a schedule
> to the
'apt-get update' Exec to limit when it can run or how many times it can run
in a given period. That way it wouldn't need to run every time an agent
applies its catalog, if that's what you're really after. That will reduce
the average load on your Apt server for metadata requests, which are
probably the bulk of the requests it services, but it will not reduce the
load from serving actual packages. If you stagger nodes' metadata updates,
however, then you will level out the load on your apt server from both
kinds of requests.