Support Debian 11 #108
Support Debian 11 #108
Conversation
Co-authored-by: Romain Tartière <[email protected]>
|
Nice! So now we need Debian 11 added to metadata.json (think about rebasing of top of master to take the changes merged by #107) and the WIP can be gone?. |
FlorentPoinsaut
force-pushed
the
FlorentPoinsaut-patch-2
branch
3 times, most recently
from
2f0a626
to
e1a9447
Compare
FlorentPoinsaut
force-pushed
the
FlorentPoinsaut-patch-2
branch
from
e1a9447
to
16c5559
Compare
|
I need help finding the right way to test my work in a smart way. |
|
For running the spec tests on your machine, you can:
|
Co-authored-by: Romain Tartière <[email protected]>
FlorentPoinsaut
force-pushed
the
FlorentPoinsaut-patch-2
branch
from
d439141
to
2e42adb
Compare
|
Thank you @smortex for your advice! |
|
LOL... |
| Optional[String[1]] $gpg_key_fingerprint = undef, | ||
| Boolean $subscription = false, | ||
| Optional[String] $username = undef, | ||
| Optional[String] $password = undef, | ||
| ) { | ||
| ) inherits bareos::params { |
There was a problem hiding this comment.
I'm wondering if that's required. Do we allow people to use this class directly or should it be marked private? the init.pp calls bareos::repository, that means $bareos::repo_release should work.
There was a problem hiding this comment.
I think we can continue to allow people to use this class directly.
There was a problem hiding this comment.
in that case we maybe should inherit from bareos instead? that would be a common pattern. Otherwise you end up in situations where people set bareos::repo_release in hiera but that won't be picked up by this class.
There was a problem hiding this comment.
As it is, it is impossible because init.pp invoque bareos::repository class.
There was a problem hiding this comment.
Then we can use this default parameter (no params component):
Enum['18.2', '19.2', '20', '21'] $release = $bareos::repo_release,No need for inheriting, we can even remove the parameter and use the $bareos::repo_release variable directly, and make the class private without impacting end-users 😉
There was a problem hiding this comment.
I'm sorry but I don't understand what is the advantage of making the param class private.
What is the problem to allow user to only add Bareos repository and nothing else?
There was a problem hiding this comment.
I am not speaking about the params class sorry… As you said, bareos::repository cannot be declared by the end-user because the bareos class declares it. So the user has no possibility to pass custom parameters unless using hiera which is not a good idea, it is some implementation detail internal to the module.
There was a problem hiding this comment.
Ooohh no, my bad, I write param instead of repository . I'm sorry.
This scenario is true only if bareos::repository inherit of bareos but we have no problem if bareos::repository inherit of bareos::param as I wrote in code.
There was a problem hiding this comment.
I believe that @smortex is suggesting to reference the repo_release parameter of the bareos class and no inheritance is needed.
FlorentPoinsaut
force-pushed
the
FlorentPoinsaut-patch-2
branch
from
c61a83d
to
fbaa120
Compare
Pull Request (PR) description
Support Debian 11
This Pull Request (PR) fixes the following issues