Consesus on Linuxconf?
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.
--If for some reason linuxconf munges the file, you should be able to go
back to the previous version easily through versioning.
*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.
*Modules for all packages that have conf files
--Is this neccesary? Can someone do a study on what the majority of conf
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.
Feel free to add more points that need to be covered for consesus.
Shaya
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: