[prev in list] [next in list] [prev in thread] [next in thread] 

List:       redhat-devel
Subject:    Re: [PROPOSAL] Configuring subsystems
From:       Jos Vos <jos () xos ! nl>
Date:       1997-06-28 20:36:48
[Download RAW message or body]

John A. Martin wrote:

>     Jos> One should be able to enable/disable subsystems on a system
>     Jos> without too much trouble....
> 
> How much trouble?
> 
>         rpm -i <file>
> 
>         rpm -e <package>
> 
> Uninstall disables.  Install usually enables except when manual
> configuration is required, as for example with diald, when the install
> can give the user a note as to what is required.

No, please...  if I temporarily want to disable INN, I don't
want to remove the INN package (and its config files, etc.).
I don't know any UNIX system that requires removing software
for (temporarily/semi-permanently) enabling/disabling subsystems.

Furthermore, if I deliver systems to customers, I don't want to add a
bunch of binary RPM's and try to explain them which packages they need
to install when they want to start using BIND, INN, etc.  Of course,
packages they really don't need and probably will never want to use
can be omitted at all.

> Please think very carefully before urging a change to the Red Hat
> convention that installing a package enables it ready to go or as
> nearly so as possible.  It could do to establish a convention and
> check that packages that do require attention after install
> consistently give the user an indication of what is needed.
> 
> Installing ready to go seems natural and is feasible for the vast
> majority of packages.  The packages that require manual configuration
> do so because of the basic characteristics of the package and
> therefore should be no surprise.  Where is it written that a packager
> cannot cause configuration aids (using menus. GUI, or whatever) to be
> invoked during package installation?

My proposal does not imply that a change is need here: the default can
be that all config files enable the subsystem by default (although I
would not recommend that for INN, for BIND, etc.).

> After installation we have, for daemons,
> 
>         /etc/rc.d/init.d/<script-name> {stop,start}
> 
> How much trouble is that?  Also, what about the Red Hat GUI
> equivalents?

The enabling/disabling subsystems is meant to be permanent (that is,
its state is not affected by rebooting, run level changes, etc.).
The use of start/stop init scripts for non-permanent state changes
should still be done.

> For configuring the startup command line could similar advantages be
> obtained by well constructed shell variable assignments at the top of
> the existing init files?  One could also put 'exit' at the top of an
> init file, no?

I want to separate shell code and config data.  Especially for being
able to make GUI front-ends or shell scripts or whatever to process
this config data.  I don't want tools to hack in a shell script and
try to put "exit" on the right place.

--    Jos Vos <jos@xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204

--
To unsubscribe:
mail -s unsubscribe redhat-devel-list-request@redhat.com < /dev/null

[prev in list] [next in list] [prev in thread] [next in thread]