Ok, I see their has been a lot of talk on if the way linuxconf does its thing is good for debian.
first things first, a user doesn't have to use linuxconf. If a user wants to edit the file by hand they can use the existing tools that we have. Even those aren't perfect, if I edit my sendmail.cf by hand, then run sendmailconfig, I can blow away what I just added. I believe we have to aim for a tool that will make most peoples lives easier in admin'ing their system, while not taking away any of the functionality of editing the files directly. i.e. The packages will work and be configurable easily without linuxconf, but if you use linuxconf you are agreeing to a compromise of some sort, in that we can't guarantee that if you are an "edit the file directly" kind of person, that linuxconf will be able to parse what you wrote. -We will work towards being able to parse what you have written, but we aren't aiming linuxconf at you. -If their is something that you what to do that linuxconf can't do, file a bug report and we'll try to add that to linuxconf Also, linuxconf shouldn't be used to configure a user's personal information, such as .bashrc, .pinerc, those should be left to either the program itself like in pine, or to a package like the dotfile generator for a program like bash or procmail. Essentially, for system wide daemons and servers, use linuxconf, for user level tools use the examples I gave for bash/pine. Something like cron falls in the middle, and I'd be willing to put that in linuxconf as cron can be both configured on the user level and system level. For the fact that we would need to write a parser for all our conf files. I think that might be overkill, as many of our conf files are probably just some files with a variable or two. i.e. the structure of the config file is constant just with a change in the "variables". It shouldn't be too hard to set up a example linuxconf module that shows how to set up a simple form that accepts input and place them into the proper slots in a model config file. This example module could be easily modfiable for all the appropriate uses. Other things are obviously more complicated, but that might knock off a big chunk of our conf files. Shaya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
