Gabriel Filion [Thu, 20 Sep 2012 07:55:58 +0000 (03:55 -0400)]
Make apt::preferences_snippet place files in /etc/apt/preferences.d
Since Debian Squeeze, apt supports a .d directory for preferences
(pinning). Simplify management by just placing files inside this .d
directory.
This removes the need for concat and concat::fragment resources, so
removes the dependency on the concat module. It also removes the need
for a moduledir that was needed for the concat module magic, so we also
get rid of the dependency on the common module.
Gabriel Filion [Thu, 20 Sep 2012 06:54:26 +0000 (02:54 -0400)]
Stop using config_file from the common module
This define doesn't add much of a shortcut and imposes a dependency on
the "common" module. We'll be better off with the small repetition but
less tightly coupled modules.
Sadly, the "common" module is still required, but that is going to be
the focus of the commit that follows this one.
Micah Anderson [Wed, 22 Aug 2012 14:57:06 +0000 (10:57 -0400)]
Add upgrade notices about the changes to parameterized classes; add a Requirements header; move things that used to be called variables into the appropriate parameterized class section
intrigeri [Fri, 8 Jun 2012 16:18:50 +0000 (18:18 +0200)]
Support multiple APT preferences snippets for the same package name pattern.
This is implemented by adding a "package" parameter to apt::preferences_snippet,
so that define names can be kept unique while the package names are
not necessarily.
Gabriel Filion [Mon, 9 Apr 2012 05:33:13 +0000 (01:33 -0400)]
Refactor: manage .d directories when using sources_list and apt_conf
The .d directories are only managed by the main 'apt' class. However,
both 'sources_list' and 'apt_conf' defines depend on those directories.
So in practice, the defines have an implicit need for those directories
to be somehow managed.
Let's turn this into an explicit relation, and include the directories
in the defines.
This makes it possible to use both defines without having to include the
main 'apt' class. (maybe when using puppet apply?)
as we use $lsbdistcodename as source we cannot name the sources
which should be used to update "stable". -> Fix it by deploying
a per lsbdistcodename configfile. This can also be used as a pre-
work for the #2681 shared modules bug.
Debian sources: don't use next release's backports.
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.
intrigeri [Mon, 7 Feb 2011 10:17:07 +0000 (11:17 +0100)]
Starting from Squeeze, Debian Volatile is deprecated in favor of CODENAME-updates.
Take this into account in the Debian sources.list template:
- go on using volatile.d.o for <= Lenny sources lines
- start using CODENAME-updates for Squeeze and newer.
Micah Anderson [Sat, 18 Dec 2010 20:47:11 +0000 (15:47 -0500)]
add -q to the apt-get invocation in upgrade_package.pp, also switch to using -y instead of --force-yes. this way we are acting in the same way as the dist_upgrade class
Micah Anderson [Sat, 18 Dec 2010 19:01:11 +0000 (14:01 -0500)]
switch aptitude to apt-get, since aptitude will sometimes automatically do things that are unrelated to the task at hand, such as deinstalling automatically installed packages, which can be undesirable behavior
intrigeri [Thu, 16 Dec 2010 12:03:08 +0000 (13:03 +0100)]
New class: apt::dist_upgrade::initiator.
This implements the "update initiator" pattern suggested by
http://projects.puppetlabs.com/projects/puppet/wiki/Debian_Patterns.
This feature is useful when one does not want to setup a fully automated upgrade
process but still needs a way to manually trigger full upgrades of any number of
systems at scheduled times.
intrigeri [Tue, 14 Dec 2010 21:04:05 +0000 (22:04 +0100)]
(ugly workaround warning) Update packages lists before upgrading a package.
... because Exec[update_apt] is currently never run since we set it refreshonly.
Better solutions are being thought of, but in the meantime the least we can do
is somehow repair apt::upgrade_package.