el Jaimito wrote:
>
> Bill said:
>
> >From what I've read here, addons should not use
> /templates-custom/. /templates-
> >custom/ is made for machine-specific customizations.
>
> Thanks for the reply. Hmm, I must be misunderstanding this. I
> based my actions on the document at
>
>
http://www.e-smith.org/custom/>
> I f I revise the base template, any upgrade would overide my
> revision. The referred doc specifically recommends using
> templates/custom for such customisations. But there's a
> problem if two authors attempt to override the *same* default
> template, it seems to me.
>
> I searched on the phorum before posting my original request,
> but found no direct reference to this issue. I *did* find one
> post jokingly suggesting three levels of templating, and
> suspect that may be related to this issue.
Yes, your customizations that you make should go in /templates-custom/. I've seen posts here that /templates-custom/ is made only for your personal customizations, and any addons should use /templates/ for their files. In other words, multipop's default files should not overwrite your custom files. They should go in /templates/, not /templates-custom/. But like you said, this can cause problems if you have two addons attempting to alter the same file. The three-level template system might help, but you'd still run into this unless you had a dir for each addon, which would probably make things ten times more complicated. Obviously, it's best if you can add a new fragment for your addon, but sometimes the existing stuff simply NEEDS to be changed...
> >When using SME, keep in mind that it's really aimed at
> smaller offices with (no) real IT staff. If they can be
> talked through entering one line at a command prompt to fix
> everything, that's much better than having them try to edit
> files and all the other stuff that usually goes along with
> fixing computers...
>
> Well, yes. I suspect you also meant not 'a command prompt'
> but 'a web form'. With the sorts of users we have, I wouldn't
> even let them near a web form
If they can handle a
> command prompt they could handle a .fetchmailrc!
I did mean command line. I meant that it's easier to say tell them to type "/sbin/e-smith/expand-template /etc/program.conf" than it is to have them load the file into pico, find the bad part, edit it out, and save the file.
> I'm starting to see that the real issue here is, what is the
> canonical reference? I hadn't really though about this
> before, but in *nix systems, the canonical reference
> traditionally used to be the .config file (or other
> plaintext configuration file) that defined the options
> controlling the system: cf Windows, where it used to be the
> *.ini file, and later moved (mostly) to the registry.
>
> But in SuSE, and RedHat, Mandrake, and of course e-smith/SME,
> that is no longer true (but with different details). The GUI
> is the implicit canonical reference in these systems (as I
> found when I tried editing config files by hand in Mandrake,
> only to have my changes overwritten by the GUI). I am now
> starting to see that this just may be injecting an extra
> level of unmanageability, in the name of simplicity of
> management.
Well, if you know what you're doing, you can delete the default templates and write your own files. However, I usually find it just as easy to make a custom fragment as to find the right part of the file and edit it. Some fragments contain code to handle all the ibays for example. Changing one little thing in a fragment can apply the change to all the ibays, and provides only one place to screw something up, instead of ten. I think (not 100% sure) you can even just write your own custom .conf file in the /templates-custom/ dir, instead of actually making a templated version of your custom file. Again, this allows a quick fix without screwing everything else up.
7 Replies
894 Views