fix for $lsbdistcodename regression introduced by 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

1 files changed, 21 insertions, 7 deletions

diff --git a/README b/README
index f4b6566..3cd341d 100644
--- a/README
+++ b/README
@@ -31,6 +31,17 @@ Ubuntu support is lagging behind but not absent either.
 
     class { 'apt': debian_url => "http://localhost:9999/debian/", use_next_release => true }
 
+   previously, you could manually set $lsbdistcodename which would enable forced
+   upgrades, but because this is a top-level facter variable, and newer puppet
+   versions do not let you assign variables to other namespaces, this is no
+   longer possible. However, there is a way to obtain this functionality, and
+   that is to pass the 'codename' parameter to the apt class, which will change
+   the sources.list and preferences files to be the codename you set, allowing
+   you to trigger upgrades:
+
+   include apt::dist_upgrade
+   class { 'apt': codename => 'wheezy', notify => Exec['apt_dist-upgrade'] }
+
  * the apticron class has been moved to a parameterized class.  if you were
    including this class before, you will need to move to instantiating the
    class instead. For example, if you had the following in your manifests:
@@ -106,13 +117,6 @@ site_apt/files/some.host.com/03clean_vserver)
 Variables
 =========
 
-$::lsbdistcodename
-----------------
-
-Contains the codename ("etch", "lenny", ...) of the client's
-release. While these values come from lsb-release by default, this
-value can be set manually too, e.g. to enable forced upgrades.
-
 $custom_sources_list
 --------------------
 
@@ -219,6 +223,16 @@ apt/preferences file to be absent:
 
   class { 'apt': custom_preferences => false }
 
+codename
+--------
+
+Contains the codename ("squeeze", "wheezy", ...) of the client's release. While
+these values come from lsb-release by default, this parameter can be set
+manually, e.g. to enable forced upgrades. For example:
+
+   include apt::dist_upgrade
+   class { 'apt': codename => 'wheezy', notify => Exec['apt_dist-upgrade'] }
+
 
 apt::apticron
 -------------