Re: Package configuration philosophy
On Thu, 27 Feb 1997, Alexander Gieg wrote:
> *All* of this, except those things about default prompts,
> are done by the LinuxConf project, a very cool system manager
> for Linux. See at:
>
> http://www.solucorp.qc.ca/linuxconf/
>
> It seems that someone is packaging LinuxConf. This software can
> also take care of the Linux's boot process, but the Debian
> developers seems don't know about it... :-(
Actually, Linuxconf has been discussed many times in debian-devel - we
definitely know about it.
Linuxconf has some nice features but it has the serious drawback that it
replaces the sysvinit. This would break every single program that needs
to be started at boot time. Using Linuxconf would require changing
nearly every important package so that they worked with linuxconf's
non-standard boot script system. Co-ordinating a massive change like
this would be a nightmare...and I do NOT believe that the end result
would be worth it - the same or better results can be achieved with far
less radical changes to current standards.
Shaya Potter is working on resolving some of these issues. I wish him
luck, but I personally feel that there are too many changes required for
it to work. Worse, it would require massive change all at once, rather
than incremental small changes over several months.
I think that the time would be better spent in coming up with our
own system configuration tools - which used plain text files so that
configuration could be changed with purpose-written command line tools,
with vi or emacs, with sed or awk or perl, or with a cgi script lurking
behing a web page. One of the number one design criteria of any new
system admin tools is that it MUST NOT require a radical change in the
way system admin tasks are done - it must fit in with what has gone
before and work as an *optional* logical evolution of existing methods.
sendmailconfig and apacheconfig are two good examples (there are others
already in debian) - they ask a few questions and use the answers to
generate the required configuration files. Those configuration files
can then be hand-customised if required.
Now these two are pretty good as they are, but would be even better if
they were split into two separate programs - one to ask the questions
and record the answers in a file, the second to read the answers from
the file and generate the final configuration file.
If this is done, then the first question-asking program can be replaced
with a suite of programs which use different interfaces (ncurses, tk,
www, etc) to ask the questions. Also, the answers file can be edited
manually with vi. Whichever method is used to generate the answers
file, the final stage remains the same: run the second program to read
in the answers file and generate the config file.
simple, straight-forward, and an evolutionary (rather than
revolutionary) advancement.
sendmailconfig is pretty close to this already - sendmailconfig creates
/etc/mail/sendmail.mc which is then processed with m4 to generate
/etc/sendmail.cf
Now take this idea one step further and define a standard format for a
questions file - what questions to ask, what types (int, char, string
etc) of answers to expect, optional questions which depend on other
answers, and where to store the answers.
Then a set of standard tools could be used for the user-interface side
of the problem which each package would use, along with package-specific
back-end scripts to do the final stage config file generation.
The linux kernel source configuration script could be used as a working
example (it already has terminal-mode, ncurses/dialog, and tk/tcl
front-ends).
This would reduce the work required for each package to just one easy
questions file, and one back-end config generator (which may be easy
or it may be difficult, depending on the package complexity). The
easier it is for package developers to use, the more likely it is to
be incorporated in the next debian release of any package....
craig
Reply to: