Closed 0x46616c6b closed 4 years ago
The addition of the dependencies
key in meta/main.yml
with abbdafdcb41349a6a492b38a56bc0a3ebf015339 broke my playbook.
i'm not convinced whether i want to use the referenced role as well. i see the point, but imo it's rather bloat given that i have to trust the repository's administrators anyway. (i configure https transport for apt packages in another role for all hosts.)
i'd rather prefer that this way of adding repos was an opt-in or had an opt-out for the sake of this role's reusability by the general public.
The addition of the dependencies key in meta/main.yml with abbdafd broke my playbook.
I'm sorry. What was the problem?
i'm not convinced whether i want to use the referenced role as well. i see the point, but imo it's rather bloat given that i have to trust the repository's administrators anyway. (i configure https transport for apt packages in another role for all hosts.)
That's true. It just limits how much you have to trust them. and it helps a bit agains stupidity ;)
What role to you use for https-transport?
i'd rather prefer that this way of adding repos was an opt-in or had an opt-out for the sake of this role's reusability by the general public.
I can see your point and would be open to accept a refactoring.
I'm sorry. What was the problem?
sorry, missed this:
ERROR! the role 'systemli.apt_repositories' was not found in ansible.legacy:/home/ansible_path/p/roles:/home/ansible_path/roles:/home/ansible_path/roles:/home/ansible_path/p
What role to you use for https-transport?
it's just one with various basic configurations. and i would argue that this configuration doesn't belong into one that facilitates the addition of a repo, as the name indicates.
I can see your point and would be open to accept a refactoring.
i see my responsibility for fixing things i broke… besides, it doesn't seem efficient to tackle a problem one hasn't dealt with yet.
To the best of my knowledge nothing is broken here. Is there a conflict with other roles or do you just think it's bloated?
there's no conflict. after the cited error message in my previous post the play that includes this jitsi-meet role aborts.
Okay. Than just please install the missing role. It now described as a dependency in the README and ansible-galaxy install systemli.jitsi_meet
would resolve this dependency automatically.
i'll have to check with my team whether we want to adopt the usage of Ansible Galaxy.
and as a thought, wouldn't it be better to improve the apt_repo
task module w/ the goals that other role wants to accomplish?
fwiw, though it doesn't technically belong here, i want to share some feedback with you.
we decided to not adopt Ansible Galaxy. also, i'm as well experiencing a lot of effort when it comes to managing the different branches that are used for PRs and one for actual deployments. hence we also agreed to persistently rely on a fork of this repo and i will probably not propose further changes.
beside the required effort, it seems that different paradigms regarding configuration and role design are an obstacle to find a common ground. speaking from my perspective, you seem to prefer the bloaty whereas i tend to the less-is-more. but i haven't any other experiences with contributing to Ansible roles, so i dunno whether and how (far) it's possible to find a design that fits as much contexts and needs as possible.
We should follow the Debian Guideline for using third party repository and add a standard pinning for the jitsi meet repository. See the explanation here: https://wiki.debian.org/DebianRepository/UseThirdParty