SCIENTIFIC-LINUX-USERS Archives

May 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Clint Bowman <[log in to unmask]>
Reply To:
Clint Bowman <[log in to unmask]>
Date:
Fri, 24 May 2013 10:14:30 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (83 lines)
The usual convention has been to designate configuration files with 
".config" or ".cfg".  That still seems to pull quite a few out of the 
filesystem.  By convention they also should be in */etc/--not necessarily 
/etc (sometimes it's more convenient to keep them in a directory structure 
rooted with the application.)

Clint Bowman			INTERNET:	[log in to unmask]
Air Quality Modeler		INTERNET:	[log in to unmask]
Department of Ecology		VOICE:		(360) 407-6815
PO Box 47600			FAX:		(360) 407-7534
Olympia, WA 98504-7600

         USPS:           PO Box 47600, Olympia, WA 98504-7600
         Parcels:        300 Desmond Drive, Lacey, WA 98503-1274

On Thu, 23 May 2013, Yasha Karant wrote:

> On 05/22/2013 10:59 PM, David G.Miller wrote:
>> Elias Persson <delreich@...> writes:
>> <SNIP>
>>> On 2013-05-22 17:45, Joseph Thomas Szep wrote:
>>>> On Wed, May 22, 2013 at 08:06:47AM -0700, Yasha Karant wrote:
>>>>> Is there a single list of the various "stock" configuration files
>>>>> and directories used by the various applications that come with EL?
>> 
>>> If it's config files you're interested in, `rpm -qc ...` should
>>> limit that to just files the packager considers config'able.
>>> 
>>> Taking that one step further, this should get you a list of all
>>> such files:
>>>
>>>       rpm -qac | grep -v -e '(contains no files)'
>>> 
>>> Keep in mind though that what the packager considers to be a
>>> config file (or for some other reason has marked as such) does
>>> not always correspond to what normally would be considered such.
>>> I certainly wouldn't have thought of /var/lib/rpm/* as configs...
>>> 
>>> 
>> In rpmbuild speak configuration files typically have two characteristics:
>> 
>> 1) The file will usually be modified after installation, and
>> 2) The modified file contains information that shouldn't be overwritten by
>> an update.
>> 
>> What we think of as configuration data fits this criteria but so do lots of
>> other files.  Probably a better name would be something like "user
>> configurable" or "configuration dependent."  Classifying a file as a config
>> file also gives the user a way to do rpm --verify and filter files that are
>> expected to not match what was installed.
>> 
>> Cheers,
>> Dave
>> 
>
> I agree -- "configuration dependent" modifiable would be a better 
> description.   At one time, these were straightforward to find, and often, 
> the man page would list the names of each configuration file and ofter the 
> functions thereof.  The source code for the application typically would have 
> a "comment" section that listed the internal layout of each such file, also 
> typically a plain text file that could be modified with a plain text editor 
> (e.g., vi).  This sort of information is increasingly difficult to find, with 
> some configuration files written as nominally plain text but in such schemes 
> as XML.
>
> I have a suggestion that could be initiated in SL and perhaps then diffuse 
> into other Linux varieties.  This suggestion would NOT cause any loss of 
> binary compatibility with other EL derivatives.
>
> The suggestion:  a specific directory that serves as a repository (not a 
> distribution repository, but one on a locally accessible host machine, 
> including the immediate machine being used).  Each application (say kile or 
> vi) that has a configuration file  would have a configuration-list file (say, 
> kile-config) that contains the actual list of configuration files, both kept 
> centrally within a system or for each user home directory, and, if possible, 
> the use/content template of each such file.  It would be up to the maintainer 
> of the application to supply this configuration-list.  Initially, there would 
> be very few of these, but as time proceeds, there would be more contributions 
> to this set of configuration-list files, ultimately addressing the problem.
>
> Yasha Karant
>

ATOM RSS1 RSS2