apt::pin: handling all apt preferences properties

[mbornoz]

The two forms of APT preferences records (general & specific) can now be
completely and not partially defined. All distribution properties can be passed
as resource parameters. This change is totally backward-compatible.

[mbornoz]

IMHO it replaces the PR #130, @uu1101 what do you think?

Otherwise, I'm trying to fix tests with puppet 2.6

[mbornoz]

@puppetlabs have you ever had this kind of errors in Travis CI? https://travis-ci.org/puppetlabs/puppetlabs-apt/jobs/8226907

[uu1101]

It covers my use-case (pinning by component), you can certainly close my pull request.

[hunner]

@mbornoz Yeah I've had those errors. Since everything else is green I usually just ignore them since it's not a failure of the specs.

If you really want to re-trigger the travis build you could rebase the last commit with git commit --amend and just save the same commit message. This will cause the commit to have a new SHA-1 hash but the same contents, and you can force push it to your apt-preferences branch and travis will re-run the tests.

As for merging, puppetlabs-apt is on the schedule for reviewing all pull requests, but I'd like to merge bugfixes, release a version, and then merge features & release again. So this PR will get merged, but bugfix PRs will come first.

Thanks for your patience, and thanks so much for submitting a quality PR! :)

[mbornoz]

We @camptocamp decided to no longer maintain our own apt module. To be able to migrate to this "most popular" one, we depend on this change and hope that it'll be merge as soon as possible. If you notice that something isn't correct, don't hesitate to ping me.

Thank you in advance and don't worry, we are patient ;-)

[raphink]

There's no need to do a git commit --amend as there's a button on the Travis interface to re-trigger a failed build without committing anything.