[debops-users] Future of debops-contrib
stuart.t.read at gmail.com
Wed Nov 29 18:45:12 CET 2017
<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:
> 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
> 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
Thanks for all your work.
More information about the debops-users