Feature/master/support non default versions #43
Conversation
Lint cleanup.
The service provider / status stuff got a little broken during the refactors. This should mostly fix it but there is still one spec failing, and I will probably also refactor the paths.pp and packages.pp into a single file together eventually.
This commit creates a new class called `package_source_info`, which has some initial framework for managing the postgresql.org yumrepo. It also serves as a container for the 'version' variable that is needed by the 'platform' class in order to use other versions of postgres besides the system default.
|
@etiennep : would you be willing to test this out and see if it still covers your use cases? It's mostly your code, with a few minor changes:
If this looks like it'll suit your needs I'll probably merge it tomorrow-ish. Feel free to add comments or whatever if you have any thoughts! |
|
I'm getting some merge conflicts with initdb.pp and database.pp btw. |
|
Yeah, I don't recommend trying to merge this into your branch... I already had to deal with a bunch of merge conflicts from both sides. I'd recommend just pulling this branch directly if you can try it out. |
|
Oh yeah ok. I'll do that. On Mon, Dec 3, 2012 at 1:27 PM, Chris Price notifications@github.comwrote:
|
|
@etiennep : so I just talked to a co-worker of mine and learned some interesting tricks that might clean this up a bit further (get rid of some of those repetitive "_real" blocks). I'll probably add a commit or two to this before I consider merging it now that I know these tricks :) But those commits should hopefully be cosmetic, so I'm still eager to hear whether or not this branch is working OK for your needs. |
Nan showed me a trick that will let us keep all of that param stuff inside of params.pp, make it a parameterized class, and still support the ability for users to specify a custom (non-system-default) pg version. This commit takes the first step towards that pattern by consolidating platform.pp and params.pp. (Everything old is new again!)
Thanks to some tricks I learned from Nan Liu and Dan Bode, I was able to figure out a way to move all of the new version-related stuff back into the params class, and clean up some of the if/_real stuff. Basic tests for centos6 + pg 9.2 are passing.
|
@etiennep I think I'm basically done with this now, with the possible exception of adding some more docs. I just added a couple of commits that clean things up a lot, thanks to some secret sauce that my co-workers filled me in on. You can see an example of how to use it in |
…default-versions Feature/master/support non default versions
This is a slight refactor of #36. It adds support for versions of postgres other than the system default, and some initial framework for managing postgresql.org package repos. It also includes the first (extremely basic) spec tests for postgres 9.2 on CentOS6.