RE: Packages should not Conflict on the basis of duplicate functionality
Looking back on it .. I guess the chkconfig idea wasn't as good as I was
originally thinking .. Irix has been the main OS at my company until
recently when I started moving the apps over to high end Linux boxes, and
have gotten used to the chkconfig setup .. (which serves more purposes than
just preventing daemons from starting .. its also used for tracing and
debugging .. ie, you can have a trace/debug log created whenever you boot,
and also use it to prevent the scripts from display a lot of info (ie, make
them quiet) .. I got used to the idea of 'chkconfig trace on' rebooting, and
using that to debug startup failures, etc... 'checkconfig autoconfig on' to
tell it to use dhcp, etc.. it just made it a bit easier than editing the
config scripts and placing exit's in them, and then removing them later ..
or removing links, and then recreating, etc...)
So, I withdraw my suggestion ;-)
-Terry
> On Sun, 3 Oct 1999, Terry Katz wrote:
>
> > Why not implement a system similar to that in Irix ( and a few
> other sysv
> > style systems ), and use a 'chkconfig' type setup..
> >
> > Irix implements it with a config directory (/etc/config), which contains
> > files with the same name as the init script or app, and
> contains a single
> > word .. 'on' or 'off' ..
> >
> > so, you can issue:
> >
> > chkconfig postgresql on
> > /etc/init.d/postgresql start
> > chkconfig postgresql off
>
> This is possibly a good idea. However, if you're gonna be doing this, why
> not just remove the symlink from /etc/rc2.d? When you want the daemon
> back recreate the symlink. I'm under the impression that package updates
> would recreate this link, so maybe that wouldn't work very well.
>
> > The modifications to add this to the distribution shouldn't be that
> > difficult .. the chkconfig (or whatever you want to call it)
> script can be
> > used to both test for and set the options..
> >
> > chkconfig [<app> [on/off]] .. leave off the last parameter to
> check for the
> > status inside an init.d script and start based on that ..
> (leave off second
> > parameter to see a complete list of whats on/off)
> >
> > The initial change to add this to the init scripts could take a while
> > (although its simple to just add it to the beginning of the
> init scripts,
> > and just exit if the config is off), but once its implemented
> it would be a
> > nice tool.. no? (every now and again it would be nice to be able to
> > chkconfig gdm off, and/or chkconfig network off, etc...)
>
> How is "chkconfig network off" any better/easier than "/etc/init.d/network
> stop" (aside from the fact it won't get restarted when you reboot)? I
> thought that's what different runlevels were for, having different daemons
> started when you boot. Maybe I'm just thinking that mucking with
> /etc/rcS.d/ as easy enough, but I suppose a chkconfig would be easier for
> those less familiar with the init system.
>
> I don't like the idea of adding this check to each init script. Wouldn't
> it be better to add this check to /etc/init.d/rcS when it goes through the
> /etc/rcS.d/S??* scripts (since the chkconfig parameter has the same name
> as the init script minus the S??)?
>
> Laters,
>
> Rick (rick@chillin.org)
> http://rick.chillin.org
>
> "As long as you want to live, everywhere will become heaven.
> Isn't that right? Because you are still alive.
> The chance to achieve happiness, you can find it anywhere."
> Yui Ikari
> Neon Genesis Evangelion, "The End Of Evangelion"
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
Reply to: