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

List:       redhat-devel
Subject:    Re: my own proposal
From:       "Willem Riede <wriede () monmouth ! com>" <wriede () monmouth ! com>
Date:       1997-06-30 21:44:44
[Download RAW message or body]

On Sun, 29 Jun 1997, Elliot Lee <sopwith@redhat.com>  wrote:
> On Sat, 28 Jun 1997, Erik Troan wrote:
> 
> > 1) Symlinks should control whteher a subsystem is enabled or not. Putting
> >    start/stop information into separate files (like Irix does) just leads
> >    to confusion. 
> > 2) Symlinks are a pain in the butt. RPM likes to put them back on upgrades
> >    and fiddling with them is quite annoying.
> > 3) Removing symlinks is a problem because the filenames include semantic
> >    information (the start/stop sequence numbers).
> 
> [Just please don't start using hard links like Solaris does by default ;-]
> 
Symlinks are the right mechanism, a convenient tool as suggested to manage 
them will soothe the "pain in the butt" and if done right streamline this 
pretty messy area.

> > Here's how I suggest solving the problem. I think Jos has a pretty nice
> > idea for providing uniform configuration information, so don't think doing
> > things this way would kill that part of Jos's propsal (though extending it
> > as Alan suggested is probably a good idea if someone could write up a
> > standard for that).
> 
> How about:
> 
> 	lines starting with # are ignored
> 	"NAME=value" format
> 	backslash continues line
> 	For each variable NAME, there should be a NAME_DESC, NAME_TYPE,
> 	and NAME_VALID_VALUES
> 	TYPE can be integer, string, float, etc...
> 	NAME_VALID_VALUES can be either a number range [m-n], a regex
> 		/myregex/, or a list of valid values (val1|val2|val3|val4)
> 	NAME_DEFAULT_VALUE can be the "sane" value
> 	The special variable "CONF_VARLIST" could hold a list of all the
> 	variables in the file.
> 	The special variable "CONF_DESC" could have a description of what
> 	the config file is used for.
> 
> Alan's idea was on the money but hard to extend if we think of new
> information we want to store about variables. This could be a start
> towards making a generic do-all configuration tool... Cool. 
> 
If I understand what is being discussed, there will be a configuration file 
somewhere in the rc.d directory tree, right? This file controls which 
subsystems are started or stopped in which runlevel in which order - if 
enabled. Since users will collect their own set of such subsystems as part of 
adapting Linux to their own preferences, this configuration file (or database) 
will get edited by users to introduce subsystems not foreseen by RedHat.

A word of warning: please keep the mechanism and file/database syntax easy to 
understand, or this will be yet another source for question after question 
from newbies.

Another consequence is (IMHO) that such user made changes can lead to 
different [KS]xx links for different installations. Therefore I suggest that 
these links are only ever made using this tool, never part of the rpm itself, 
so that the numbers that the user defined (hey if (s)he changed it they should 
know what they're doing) are obeyed.

All this is consistent with the arguments I see made (and strongly support) to 
respect to the utmost the configuration changes that the user has made. 
Nothing is more irritating than to have to do that over and over again as you 
upgrade. Though I would like to see a flag for rpm that says "please reset the 
configuration for this package to the default" for when the user (I :-) has 
made a big mess of things and needs to get back to a defined state.

Regards, Willem Riede.

--
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]