Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for pins class parameter #561

Closed
wants to merge 5 commits into from

Conversation

rfdrake
Copy link

@rfdrake rfdrake commented Sep 1, 2015

This lets you send apt::pin resources as an apt param hash. This is a
very simple change that is just like sources, ppa, settings and other
options.

This is mainly to make supporting pins in foreman easier.

settings should be source here
This lets you send apt::pin resources as an apt param hash.  This is a
very simple change that is just like sources, ppa, settings and other
options.
@@ -4,7 +4,7 @@
define apt::pin(
$ensure = present,
$explanation = undef,
$order = undef,
$order = 50,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does this come from, and why? This affects far more than just the feature you're trying to introduce.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how. Nobody can use the module without setting a pin order when $order = undef. If you try then you get this error message:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: apt::setting priority must be an integer or a zero-padded integer on node vagrant.box
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Which is confusing since the problem comes from "order" and not "priority" and from apt::pin and not apt::setting. I had to read the source to figure out what was going on.

So I could update the docs to show that order is a required value for apt::pin, but it's not reflected in any examples:

apt::pin { 'karmic': priority => 700 }
apt::pin { 'karmic-updates': priority => 700 }
apt::pin { 'karmic-security': priority => 700 }

It's mentioned in the apt::pin documentation but only to say it's an optional value and the default is 50.

Sorry to slip this in. I honestly thought it was a minor change that was probably what everyone intended. If this is truly not the case then I could update the documentation as stated, or leave it to someone who knows better what apt::pin is supposed to be doing. :)

I'll upload some tests in a couple of minutes.

@DavidS
Copy link

DavidS commented Sep 2, 2015

As daenney say, please do not change the behaviour there. Fixing the documentation instead is much less surprising to people having that in production.

Additionally, please add a test for passing the data through correctly, like it is done for ppas: https://github.com/puppetlabs/puppetlabs-apt/blob/master/spec/classes/apt_spec.rb#L206

Futher clarification is needed on what to do, but if it
should be changed or documented it should probably be in a different
pull request.
@daenney
Copy link

daenney commented Sep 3, 2015

Alright, this is looking much better. If you could squash everything into a single commit with a good description like "Add support for creating pins from main class" and if you feel like elaborating further in the commit that would be great.

Once that's done I'm OK on merging this.

@rfdrake
Copy link
Author

rfdrake commented Sep 5, 2015

Closing this since it has been reopened with a new squashed commit.

@rfdrake rfdrake closed this Sep 5, 2015
@DavidS
Copy link

DavidS commented Sep 7, 2015

Merged in #564

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants