Re: use and abuse of debconf
On Tue, Jan 16, 2001 at 10:41:19AM +1100, Brian May wrote:
> I was thinking about that too, but it can only work for extremely
> simple stuff.
mmm... I'm not sure...
> For example, consider trying to write a automatic debconf front end
> for /etc/network/interfaces, where multiple entries exist (sidenote:
> does debconf support this?). Do you think a template system can cope
> with this?
well, why not? advanced template systems use loops (and are quite simple to
use)
Let me use phplib template system style template, with witch I'm familiar:
<!-- BEGIN interface -->
iface {iface} {family} {method}
address {address}
netmask {netmask}
network {network}
broadcast {broadcast}
gateway {gateway}
<!-- END interface -->
(for those unfamiliar with this block, it's simply a loop of the iface
statement)
For up, down, pre-up, post-down options I was thinking about an alternative
solution, like that of rc scripts with a per-interface configuration and a
tool like update-* (when I'm done I'd like to know what the ifupdown author
say).
This should work fine.
> Then have a look at the Kerberos configuration files:
[...]
> Now, try adding, deleting, or modifying realms from this file without
> messing around with any settings/comments that the user has made, with
> a template based system...
Suppose that I can make a template (with witch I mean one or more files), and
suppose that user has just configured Kerberos with debconf; values are stored
in a db, so they can be retrieved, and used to rebuild the configuration, and
then you can add whatever you want.
But, what I mean with template system to configure, is for first configuration
or inexpert user configuration. If you are talking about expert users that
open configuration file and add or remove fields and play with configuration,
you probably are talking about people who do not need for a tool that
configure their application, and would hit "take may old configuration" when
upgrading.
> Another way would be to design the source file using XML, with all the
> detail that is required to produce the destination file.
[...]
> Alternatively, a future version of the program may read the
> XML file directly, without the need for this intermediate step.
>
>
> I think there is one big problem (one that I would accept, but others
> may not): users would have to become accustomed to editing the XML
> file each time, and not the final destination file, and then run some
> conversion program (perhaps XSL based) to output the destination file.
Not only: maintainer should write the XSLT and transformation is computational
heavy.
> Still more and more packages seem to be using templates in some
> way or another, and this is already required.
Not only: template systems are easy to implement, and may still do clean and
fine jobs.
> I think using XML is a more consistent approach, as all programs could
> follow a similar path (some standard is required here), and I would
> consider this a good solution. It means that any program that alters
> the configuration file only needs to know the XML format (eg. postinst
> script, XML editor, etc). At the same time, existing tools (eg text
> editors) will work fine, as XML is text format.
I agree, but what I'm trying to say is that, IMHO, it's not the time to
introduce XML: we may go trough steps, starting from template, for examples.
Whatever you wont to do with XML may be done now with templates: not as
organic as XML, not as portable as XML, but faster and easy to implement, by
now.
Regards,
--
Luca - De Whiskey's - De Vitis
Undergraduate Student of Computer Science at Bologna University.
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$
e-mail: devitis at (students dot )?cs dot unibo dot it
homepage: http://www.Students.CS.UniBO.IT/~devitis
anti SPAM: s/\ dot\ /./ , s/ at /@/ && solve_regex(e-mail)
Reply to: