[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linuxconf

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

Reply to: