| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
with the release of squeeze-lts, the current way we deal with security
sources is problemaic. by flipping things around we hope to make the
files contents more stable.
|
|
|
|
|
|
|
|
|
|
Both have been unsupported for ages.
|
|
next_release was forgotten when next_codename was fixed.
|
|
ac166366d7baa45b74e09974289d9fb2dad38e67
What happened here was the $codename = $::lsbdistcodename was removed from
init.pp and replaced with just $::lsbdistcodename whereever $codename was
used. Then in the sources.list.erb and preferences files things were changed
like this:
<pre>+### Debian current: <%= codename = scope.lookupvar('::lsbdistcodename') %>
...
-deb <%= debian_url %> <%= codename %> <%= repos %>
...
+deb <%= debian_url=scope.lookupvar('apt::debian_url') %> <%= codename %> <%= repos=scope.lookupvar('apt::repos') %>
</pre>
This meant that the codename was always set to lsbdistcodename, and you because
in newer puppet versions you cannot assign a value to a top-level facter
variable, it is not possible to change this.
Because we cannot change $lsbdistcodename, we have to fix this by allowing the
user to pass a different, non-top-level scoped variable to the class as a
parameter, which defaults to $::lsbdistcodename, so that upgrades can be
triggered.
This is documented in the README in an upgrade notice
|
|
|
|
Conflicts:
README
manifests/dist_upgrade/initiator.pp
manifests/init.pp
manifests/preseeded_package.pp
manifests/unattended_upgrades.pp
|
|
parameter is not set.
Details:
https://labs.riseup.net/code/issues/3467
https://labs.riseup.net/code/issues/3468
|
|
the actual repos are in real_repos as by default we have auto.
|
|
Closes: Redmine#3467.
|
|
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.
Closes: Redmine#3468.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... else the first block added by apt::preferences_snippet is in the same
paragraph as the last block provided by the template.
|
|
|
|
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.
|
|
This is now done automatically by APT.
|
|
|
|
The previous template was indeed ensuring no package from squeeze-updates could
be easily or automatically installed.
|
|
Every needed function has been updated since Squeeze was released and we can
thus use a nice generic template.
|
|
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.
Reference: http://lists.debian.org/debian-volatile/2011/01/msg00008.html
|
|
|
|
|
|
|
|
|
|
namespace like that
|
|
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.
|
|
This is needed when using apt-listbugs with an APT proxy that only {wants,can}
proxy "normal" APT traffic.
|
|
|
|
|
|
upgrade_package functionality, because you get an email when the package has been upgraded.
|
|
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
e2f80db7b76171e5945127e2fd42fb35043990fb 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.)
|
|
Conflicts:
README
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
|
|
A bunch of painlessly merged commits.
Conflicts:
manifests/init.pp
|
|
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
|
|
(Starting to merge changes from immerda.)
Conflicts:
manifests/default_sources_list.pp
manifests/init.pp
|
|
apt preferences actually want // to comment, while sources are fine
to be commented with # ...
|
|
|
