Apt update tooling

[wolfspyre]

This gives you the ability to have puppet run apt-get update a few different ways:

• always
• daily
• weekly
• reluctantly default

it determines when to trigger the apt-get exec via a combination of an addition of a script in apt.conf.d that touches a file when apt-get update runs, and a custom fact which checks the mtime of that file.

all behavior should be covered by spec tests.

additionally fixed up the spec tests to function when running natively on non-debian systems

Please let me know if there are any changes you'd like to see here in order to merge this

[daenney]

The current test failures aren't your fault. Travis installed puppet-lint 1.0.0 which is currently wreaking havoc on things that arre perfectly fine. Once we get this sorted we'll ask you to rebase your PR and we can take it from there.

[hunner]

Instead of using collectors and overrides, could you just use a variable?

[daenney]

Could you rebase this on master for a sec? That should get the tests going and we can see if this can be merged.

[wolfspyre]

Done.

Let me know if you need anything else here.

[daenney]

Looks like this passes now, thanks!

[underscorgan]

You should not include apt here. It is fair to assume that anyone using apt::update will have already included apt with any necessary parameters before they include this class.

[wolfspyre]

Really? I've always been under the impression that it was a good practice to include the parent class when referencing parent class parameters/variables from a subclass. This gives one the ability to have unit tests behave as expected (although that could be solved by pre_condition assertions), and tries to do the right thing if the subclass is invoked before the parent class for some crazy reason. Is there any harm in this? or is it simply a smell issue?

[daenney]

It's not just a smell issue, it can cause errors at runtime. It's a bit of a Puppet internal thing. The problem is the following. If you have multiple declarations of the same class in this order:

class  { 'apt': params }
include ::apt
include ::apt

This will work.

However, if the evaluation order changes and we end up with:

include ::apt
class { 'apt': params }
include ::apt

This breaks. You can't re-include a class once you've initialised it with the class parameter syntax. So just including apt everywhere can cause trouble.

This almost never happens in real life because everyone is a good citizen and just includes the top class in their catalog.

MY preferred way is to access variables from other classes using a 'normal' lookup, so $::apt::var. In Puppet 2/3 this has the unfortunate side-effect of the variable becoming undef if you forgot to include the top class so it might break in weird-ish ways, but it'll break. In Puppet 4 you'll simply get an error stating that $::apt::var is not defined (turn strict variable checking on in Puppet 3 and you get the same).

[underscorgan]

@wolfspyre other than my two inline comments, I think all we need is for this to be squashed down to a single commit. Thanks.

[daenney]

@wolfspyre Are you around to rebase and squash these commits? We'd like to release somewhere next week and have this ship with it.

[wolfspyre]

@daenney How's that?

[daenney]

Awesome, thank you. As soon as @mhaskel is back in the land of the conscious we'll get this done.

[underscorgan]

@wolfspyre thanks for the contribution!