First, allow me to state a couple of beliefs about templates.
1. I believe the templates in /etc/e-smith/templates/* should only ever be modified by an SME update or patch. Nobody else should ever add, modify, or deletes templates in that tree.
2. I believe the templates in /etc/e-smith/templates-custom/* should only ever be modified by the end-user. Nobody and nothing else should ever touch those templates.
If, for example, I want to modify a template and create a fragment in templates-custom, then nothing else should touch that template. Certainly, no contrib should come along and change it.
Likewise, neither me nor a contrib should ever touch the stock "as-delivered" SME templates. At any time I should be able to remove all customizations and have my server revert to its default (aka, functional) state.
Therefore, I propose what is needed is a third tree in the templates system -- a contribs tree. The /etc/e-smith/templates-contrib/* tree would sit between the existing templates and templates-custom trees, providing a place for contrib authors to put their templates, without worrying about overwriting either the stock or locally customized templates. The precedence would be:
/etc/e-smith/templates-custom
/etc/e-smith/templates-contribs
/etc/e-smith/templates
Similar contribs trees would be necessary for the templates-user tree.
As it turns out, this is incredibly easy to implement. The following diff output shows the necessary changes (based upon the Mitel 6.0 final):
# cd /usr/lib/perl5/site_perl/esmith
# diff templates.pm templates.new
175a176
> /etc/e-smith/templates-contribs
181a183
> /etc/e-smith/templates-contribs/etc/host
193c195,196
< will be used instead of /etc/e-smith/templates/foo
---
> will be used instead of /etc/e-smith/templates-contribs/foo, which will
> be used instead of /etc/e-smith/templates/foo.
262a266
> '/etc/e-smith/templates-user-contribs',
322a327
> '/etc/e-smith/templates-contribs',
Only the last change is actually a code change. The others update the perldoc to be correct.
This change makes it the responsibility of contribs authors to ensure only that they are able to co-exist with each other. They do not have to worry about modifying end-user changes or pristine original templates, both of which should be forbidden activities.
I would like to submit that this is a worthwhile change, and a simple change. If this could be added to 6.0.1, and published as a development standard, I think it would be beneficial to all.
Scott