The APT pinning we ship does not support that, and this seems a bit too much of
a corner case to me to deserve being supported out-of-the-box.
Anyone willing to use current release + next release + next release backports
(e.g. Lenny + Squeeze + squeeze-backports) can anyway do so using
apt::sources_list and apt::preferences_snippet.
https://labs.riseup.net/code/issues/2856 is the bug that triggered this change.
Lenny's APT does not support pinning like this:
Pin: release o=Debian,n=<%= codename %>
We therefore switched (in commit ef2ebdffd) to:
Pin: release o=Debian,a=<%= release %>
With such a pinning setup, when Squeeze is released, systems using this module
with $apt_use_next_release set to true would immediately switch to prefer
packages from Squeeze. If an automated upgrade process is setup, they would be
automatically upgraded to Squeeze.
This does not sound safe to me, so let's use the release version number as an
additional selection criterion to prevent upgrades to Squeeze to happen behind
our back:
Pin: release o=Debian,a=<%= release %>,v=<%= release_version %>*
Note that the trailing '*' is intentional and necessary to match stable
point-releases.
Why apticron, when we have cron-apt already? Some people have different preferences, we use apticron along with the upgrade_package functionality in this module. I know someone who uses cron-apt to run the upgrades, but apticron for notifications, because apticron's notifications are much nicer (cron-apt just gives you the output of apt-get upgrade)
the templates/Debian/preferences_lenny.erb file checked in with
e2f80db7b7 contains pinning based on codename,
which is not supported in lenny (see #433624 - if you look at the version graph,
you see, "Fixed in version 0.7.21", and lenny has 0.7.20.2+lenny1.)
Merging one more commit.
Conflicts:
files/preferences
templates/Debian/sources.list.deb-src.erb
templates/Debian/sources.list.volatile.erb
templates/Ubuntu/sources.list.backports.erb
templates/Ubuntu/sources.list.deb-src.erb
File headers are there to indicate that the files should not be touched
directly on the server. By changing the first sentence to "This file is
managed by Puppet", we reinforce the idea that it is already taken care
of by something else.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
The current proxy_client template makes it possible to communicate with
the proxy only via HTTP. Add the protocol to the variable so that it's
possible to change the protocol.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
Currently, it's either we use the default source that's hardcoded in the
sources.list template or we redefine entirely this template.
Make it easier to just change the URL of the apt source while using the
rest of the default template by adding a $main_apt_source variable.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
Simplifications: make apt_conf_snippet repeat less code, make code that
generates sources.list more concise.
Remove all inline content in favor of templates and static files.
The ability to include sources for static files was needed for
the main 'preferences' file, so it was added to the preferences_snippet
define.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
With the new define, it's easy to add an apt.conf snippet in apt.conf.d
It accepts either 'sources' to get a static file or 'content' to define
content inline or with the help of a template.
Put it to use where we create files in apt.conf.d
Finally, fix the dependancy to the apt_config file (however, I don't see
the need for this dependancy)
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
mirrors that are closer, or internal proxy mirror configurations
should be set in the $custom_sources_list instead so that the default
is kept as generic as possible
