On Tue, Jun 02, 1998 at 05:24:10PM +1000, Craig Sanders wrote: > > > if a program edits it too, it should do it in a way which does > > > not interfere at all with that human's right to put whatever s/he > > > desires in the file. if it can not guarantee that 100% then it > > > should not edit the file. > > > > With the exception of sendmail.cf, linuxconf does this. > > so i can make any arbitrary change to any config file which linuxconf can > work with, and linuxconf will: > > - not freak out because of some weirdness i did > - not freak out because of some perfectly sensible thing i did > - not lose any information (not a single byte), including comments and > the order/location of comments in the file Yes. And if it does lose info (again, sendmail is currently the exception) it's a bug to be fixed, not a design limit to live with. > if that is the case, then i withdraw my objection against linuxconf > editing config files directly. It was my second objection---the first was the X requiremet (which I find out wasn't the case either) > RE: sendmail.cf > > IMO, linuxconf should manage sendmail.mc rather than sendmail.cf. That would be more reasonable, however not all that sendmail can do is supported with the m4 rules and such. Not at the moment at least. Sendmail is their selling point because of how complex it is, how little m4 helps and how much they can do with it. The motivation for the project is that sendmail if easy to configure could sell linux and the opensource paradigm to a few people. This is good. The solution of course is to extend the m4 stuff to support all the things linuxconf does, but that's not so easy. Also, note that slackware didn't at last look have m4 sendmailconfig. Another example of where slackware is doing more harm than good these days by not adopting things the rest of the world has... =p But that's another argument.
Attachment:
pgp_0Tk20OJch.pgp
Description: PGP signature