Re: N-way system (was Re: Offer of help)
> > I disagree about the worthlessness of templates. In many cases, you do not
> > want to keep your old values. For example, if you change your domain name,
> > you want all references to your old domain name to change to your new domain
> > name without having to change them one by one. You might not event know in how
> > many config files they appear. That's something that templates solve trivially.
>
> Nothing to do with templates. Any package that needs the domainname
> would have to use NETWORK_domainname. If that is changed, all packages
> using it will get the new value.
Can you illustrate how the exact procedure would be in your system? Once the
user has changed a value in the front-end, how does this change propagate
to all pertinent config files? How would it be for the other case I mentioned,
say a change from connection=modem to connection=net? Please describe it
with these examples.
I know how it would be with templates. You just regenerate all config files
whose templates contain the NETWORK_domainname variable. For the latter,
just substitute NETWORK_connectiontype instead.
I guess in your case you would re-run all "configuration" scripts which
contain those variables preceded by one of your dpkg-* interfaces. Is that
correct?
But then, you would have to go through the front-ends of all those packages
affected by the change. There is no back-end only solution in your model.
Correct me if I am wrong.
> > About set_var being more difficult, I find it surprising. Using templates,
> > set_var is usually trivial. All the alignment and extra spaces is just
> > copied from the template with 0 effort from the developer.
>
> And no respect for the stuff the user changed. Maybe the user has
> added additional comments or changed the indentation of
> comments. Respecting this is what makes set_var a bit more difficult,
> but its possible with a two way system and is has to be that way.
Sometimes users do stupid things and might want to re-generate the whole thing
from scratch. Sometimes the added comments do not apply any more when the
values are changed. They will create more confusion. Keeping meaningful
comments and discarding useless ones is very tricky. Keeping all comments
might create a lot of confusion. There was a discussion two years ago in this
same list about whether or not to keep comments in config files. It should be
in the archives. I might have a copy somewhere if it's not. I could send it
to you if you want. Very risky business.
One more question. What if the user upgrades a package but the format of
a config file has changed? Would your system be able to regenerate it or would
the user have to go through all questions again? (or assume defaults and edit
the config file afterwards)
> The maintainer knows his code, or should, if he can't figure out how
> to write a get_var and set_var, he should think about changing his
> configfile format.
The maintainer is not the upstream author usually. The upstream author must
be familiar with his code. Not so for the maintainer.
> Most unix programs have a pretty simple conffile
> format, seen as LALR grammar. I will write a set_var and get_var
> template that uses such a grammar to set and extract variables, the
> maintainer than just needs to fill in the grammar and off he goes.
That's very good indeed. I wish you good luck!
Besides, if _you_ write it, then _I_ won't have to write it :-)
That's the beauty of free software.
Fernando
Reply to: