6:45 p.m.
<snip discussion of php roles>
Thanks for the helpful pointers.
I think that question deserves a more extensive discussion. I would
like to
see DebOps in Debian 'main' component of the Debian Archive at some point.
That means that DebOps, at least the main project repository, should conform
to the Debian Free Software Guidelines:
https://www.debian.org/social_contract.html#guidelines
Packages in the 'contrib' component usually depend on non-free software,
either in Debian 'non-free' component or on external software. So how does
that look if DebOps has roles that depend on non-free software? I believe that
the same rules would apply, and that would force the DebOps package to be
included in the 'contrib' component of the Debian Archive, so let's avoid
that.
But, the non-free roles and playbooks could be managed in a separate git
repository. You could install that repository alongsite DebOps monorepo, say
in ~/.local/share/debops/debops-contrib/; all there is is to update the
'debops' scripts to handle multiple playbooks at once and allow configuration
of multiple role/playbook directories where the script points Ansible at.
This would probably call for restructuring of the 'site.yml' playbook, so that
not all roles are executed at once and runs can be faster. When the CLI
supports selecting multiple playbooks to run, some more esoteric roles will
probably be removed from the main playbook.
Of course for this, an entire separate organization on GitHub is unnecessary;
there could be just another repository, say, debops/debops-contrib, with
similar usage patterns as the main repository. Fork it, add your roles to it,
make a pull request.
I agree completely that the future separation should be based upon
suitability for Debian main/contrib in order to promote efforts to
package debops. I like the idea of using a separate git repo for that
as well.
Thanks for all your work.
Stuart