Re: RFC: A method to use Admin tools, like linuxconf (Summary)
I'm going to fwd this message to the author, but I will respond on my own
to some of the comments.
On 21 Feb 1997, Manoj Srivastava wrote:
> Hi,
> Ok. I would find Linuxconf acceptable if:
> 1) linuxconf is optional
That's all I wanted.
> 2) It coexists with current init methods
It will not just coexist, I proposed that the "configure" program will
make all the appropriate links that SysV wants. (if this is what you
mean, if not please elaborate)
> 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
Yes, since "configure" makes all the appropriate links into rc*.d, all
one has to do is remove Linuxconf and SysV init should be back in place.
We can even have Linuxconf ask a question during configuration, such as
"Do you want Linuxconf to take over the job of activating Daemons (Y,n)".
So that people who want to stick with SysV, but also want to use some of
the features of Linuxconf can use it to.
> 4) We don't scrap init in favour of the LinuxConf activator
> Reason:Allowing one to choose activators at will requires a far
> stricter auditing - we'll have to not only make sure that both
> activators were working, but that one may switch back and forth
> at will. Our bug list is long enough without adding this added
> complexity. If the Linuxconf is that much better, move to it,
> and junk init (it would have to be seriously better).
Agree
> 5) LinuxConf uses /etc/init.d scripts where available
Actually, I thought of making it a must. The Linuxconf drop-ins which
are made automatically by "configure" should probably only be daemons,
and therefore have /etc/init.d scripts. Also, I like the start-stop
program we use, it makes it so that we don't have to figure out where the
program keeps a PID file and such. I am thinking that maybe Linuxconf
could include it, for the other distributions, and show users how to wrap
their daemons into it, but that's for Linuxconf's author to decide.
> 6) We should not have to modify dpkg (hah!) or seriously modify
> packaging policy.
The only thing, maybe, that dpkg would have to be modified would be to
allow for a file "database" to be included in DEBIAN/ of the package and
to install it under /var/lib/dpkg/info/(pacakge).databse. The configure
program would then look in (package).databse to get all the info it needs.
> 7) a config tool should be *only* a config tool.(IMHO)
Agreed, that the tools should probably be seperate, maybe even something
like PAM, where you can use any init type thing you want, and still be
able to use the tool in all its glory, but Linuxconf is here now, and at
this point, they probably wouldn't listen to us if we asked to change it
greatly.
>
> I'm not sure whether this can be done, and whether it would
> still be worth considering. If this can be done, go ahead and package
> it. If this can't be done, or requires major reworking of dpkg or our
> package built methods, IMHO we have more pressing things to do at
> the time (like fixing dselect and whittling down bug lists) than for
> a enhncement of something that is not broken.
Agreed. What I was wondering is, maybe we can write a Linuxconf module
for dselect. Why. b/c then people would have access to the module
through 3 differnt interfaces automatically. ncurses, x11, and web, but
this is just wishfull thinking for now. Maybe when I come back from
Israel after the next school year, I'll look into it, but that is far,
far away, a long time into the future.
>
> Question: ``Linuxconf has its central config file and that only
> contains the data that there is no standard place to put.''
>
> Can one configure what Linuxconf is data that has a standard
> place? (/etc/news/organization contains the organization string on
> Debian systems. but may well be considered non-standard as far as
> unices are considered.
I'll talk to its author about this, also we can help by putting stuff
like ethernet config info into a seperate file, which the scripts or
Linuxconf can parse easily.
>
> manoj
>
> ps. Don't get me started about ADA.
Hey, the FSF made one of the first compilers for it, so it can't be that
bad :-).
Shaya
--
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: