Re: Consesus on Linuxconf?
Shaya Potter <spotter@kby.netmedia.net.il> writes:
> I was wondering if we have reached some sort of consesus on Linuxconf.
>
> The points that I see are
>
> *Linuxconf can't lose any info.
> --This might mean that Linuxconf will error out if it can't parse the file,
> if you've made private changes to it. That's the tradeoff, you take a risk
> that you won't be able to use linuxconf if you privately edit the file. We
> will work to improve the parser though to minimize that risk.
This will be the case with any interactive config-program build on top
of existing configuration languages (even the samba configuration
"language" is complex enough for this to be true).
[...]
> *Linuxconf isn't only way to configure system? (is this a point of contention?)
> --We should continue to provide similiar tools to what we have now to be
> able to configure the system.
> ---If we do the above, should it be interchangably b/w linuxconf
> configuration system and old configuration system for the same package (i.e.
> on one computer, I can switch easily b/w sendmailconfig and linuxconf
> sendmail configuation). I think that might be too difficult to pull
> off.
> We should say that you can choose for each packages b/w the old method or
> Linuxconf's, but shouldn't switch b/w the 2 methods for one package, at
> least not expecting the data to be fully transalatable.
It should be possible to disable the linuxconf module, and perhaps
tell linuxconf to start sendmailconfig instead, or warn the user when
switching configuration methods.
> *Modules for all packages that have conf files
> --Is this neccesary? Can someone do a study on what the majority of
> conf
IMHO not nessacary
> files are, i.e. are they free flowing (i.e. don't have a set form and can be
> on any length), or are they a simple form with plug in variables, or are
> they a combination of the two. writing a module for the first case will be
> more difficult, while writing a module for the second case should be very
> easy, and we can provide an example module to show how it's done. The
> thirds case will probably be slightly difficult as well, though I'm
> not sure.
most configuration files can be complex; take a look at the files in
your /etc. How many simple and how many potentially complex files did
you find?
Additional points I would consider important:
- how difficult is it to write a module for linuxconf for some
package; can some scripting language be used?
- how well does linuxconf scale (what if i have 50 configuration
modules?)
- how clean/flexible/modular are the concepts? Will the framework
break down 3 year from now because there are so much new
requirements that can't be integrated?
- on which platforms could it run or made to work? (administrating a
bunch of machines with the same tool would be a plus; i think it's
one goal of coas)
These are general questions relating to any such program. Perhaps it
would be a good idea to discuss the interfaces to packages. If one
could standardize that (how to put additional information into
sysv-initscripts, and which information, or the module api, etc.),
perhaps we could get less dependent on a specific program like
linuxconf.
I'd like someone to package linuxconf for debian (an experimental
release), so it's easier for everyone to take a look at it. Last time
I looked at it (I think it was november 1997), I wasn't very convinced
of it's concepts. My impression was it's a monolith (though there is a
clean interface for front ends), and I didn't like the module api very
much (I experimented with a python interface module, which lets you
load modules defined by python scripts, but the overall architecture
wasn't very convincing). Is everything prodived by modules by now,
e.g. adding users, and how much (e.g. path names) is still hardcoded
and buried somewhere?
I also looked at coas (and started to define a interface to front ends
like in linuxconf, which is an area where coas is lacking), but it
seemed like development was stalled for some time. Now v0.11 has come
out, but i'm not sure if it's gaining speed (if it does i'll take up
the work on it again). The concept of coas seems to be much cleaner,
concentrating on infrastructure. Did anyone succeed in compiling it
under debian or installing the rpm's under debian? The official
compile uses libc5 and python 1.4, and the binaries in the rpm are
looking for libncurses.so.4, a libc5-readline in /usr/lib, etc. Btw.,
is there any document about the outcome of the BOF on LSB at
Linux-Expo? It would be nice if installing a rpm with alien under
debian would be easier than recompiling the source.
ciao
Andreas
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: