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

Re: More Linuxconf Stuff


	I have spent some time digesting the information that you
 forwarded from Jacques Gelinas <jack@solucorp.qc.ca>. I am commenting
 on the mail message below. 

	However, I feel that Linuxconf is a wonderful, flexible,
 configurable config-and-boot system. But it ay not work for us. We
 have been doing a lot of the work that Linuxconf does (portably, too,
 it seems), but not compatibly. In order to fit into our current
 scheme, which has done some of the things that Linuxconf does (but by
 no means all), we would have to seriously restrict Linuxconf
 (lobotomize come to mind), and that may be hard work (removing enough
 functionality from Linuxconf so that it works transparently with our

	Looking at Linuxconf, though, I think you should propose that
 we junk the current setup, and go with Linuxconf. Linuxconf does seem
 to add the level of configurabilty to systems operation that we have
 brought to modular upgrades. If it is as good as the proponents
 claim, it would be worth it, and may well give us the edge we need.

	If you do put in such a proposal, download and include the
 features web page http://www.solucorp.qc.ca/linuxconf/features.html,
 as well as the examples and excerpts from Jacques Gelinas

	I might even support you on that. I still have misgivings
 about mixing and matching.

1) linuxconf is optional
2) It coexists with current init methods

 Here, rc.boot should be modified to include a call to
 /sbin/askrunlevel, and /etc/init.d/rc should call /bin/netconf

	What do these scripts do, I wonder? is askrunlevel
 interactive? if netconf exists on the machine, we seem to bypass all
 the scripts in rc.d (unless netconf later call them, after looking at
 dropins.  Hmm. Synchronizing the rc.d and netconf methods could be
 -- painful.

3) The process is reversible, i.e., it is just as easy to remove
   LinuxConf as it is to install it, without hosing the system

 Ok, so Linuxconf can generate my sendmail.cf (unlike what the author
 claims, our config scripts seem to generate sendmsil.cf just
 fine). What about IP aliase? In anycase, if you remove linuxconf,
 sendmail.cf should remain, so that is not a problem.

 What I'm still aprehensive about is that linuxconf does something
 (unique features, the man said) unusual, and ``some features do not
 activate''. Lots of angry users may be the result of this -- but I'll
 defer to the will of the developers here.

4) We don't scrap init in favourof the LinuxConf activator

 ``linuxconf does not replace /sbin/init''
 ``linuxconf does not replace init. This person has no idea what is
	True enough.
  ``It is a seriously better.'' (example of how linuxconf saved the day.)
 6) We should not have to modify dpkg (hah!) or seriously modify
    packaging policy.
    ``Mostly, for each package, do provide another file which
  will be droped in /etc/linuxconf/control in the same way to drop a new
  file in /etc/init.d''

	This is a change (maybe minor) in the packaging policy.

7) a config tool should be *only* a config tool.(IMHO)

 [advocacy of the Linuxconf activator]

 I'm slightly concerned that Linuxconf's view about ``informations
 which has no counterpart to most unix systems''. Debian, too, in not
 like most unix systems, and there may be a mismatch here. I have no
 idea how easy it is to fix.


 "I don't believe in god because I don't believe in Mother Goose."
 Clarence Darrow
Manoj Srivastava               <url:mailto:srivasta@acm.org>
Mobile, Alabama USA            <url:http://www.datasync.com/%7Esrivasta/>

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com

Reply to: