Smart configuration file updater (/etc) suggestion

[mario]

Configuration file updater suggestion:

Description: smart configuration file merger without or with minimal user input. I.e. if a user has taken their time to configure a software product once, their preferred options are recognized and kept without his input (i.e. if they want to review a new option they can still do it but everything else is already set to their taste). Requires port/ebuild maintainer's serious attention, for example: if a new name is given to an option in a configuration file, maintainer needs to indicate that (or an intuitiveness engine can guess if for example a name of a section is changed by looking at its subsections - but this is dangerous). User can specify global options like - never update my configs, or never force new values (this is explained further).

Whatever is referred to as "directives" below can be contained in ports (ebuilds) under a special section

Scenario:

Upon software installation ( typos are on purpose )
/etc/bar.conf is installed, file contains:
# this is by low
AllowFatChicks Yes

# say no here as it is still beta
AllowTransvestites No

# You never say yes here
AllowRetards No

# this may eventually change to yes
AllowRemoteControl No

copy of file is placed in /etc/default

User edits /etc/bar.conf
# this is by low
# i don't care about it
AllowFatChicks No

....

# this may eventually change to yes
# !keep
AllowRemoteControl No

User updates software,
Port maintainer has entered a new config-updater's directive: "replaceopt AllowRetards AllowMentallyDisadvantagedPeople"
/etc/bar.conf is scheduled for replacement, replacement file contains:
# this is by law
AllowFatChicks Yes

# now it's stable, say yes here, as it is by law...
AllowTransvestites Yes

# option name changed for political correctness
# You never say yes here
AllowMentallyDisadvantagedPeople No

# mike: i think this is secure, i tested it right away when i got that cvs access
AllowRemoteControl Yes

Same file is scheduled for placement in /etc/default

Updater compares this file with previous default and current active config
It discovers the following:
1) AllowFatChicks comment changed from previous default, user added comment
Merging procedure: replace default (unchanged) comment but append user comment
2) AllowFatChicks default value did not change, however user has changed it in current config,
update new config to keep user option (overridable by forceoptionvalue for critical changes)
3) User has not modified comment or value of AllowTransvestites, however new default file has changed it, so updater updates it to new default value
4) Apart from updating comments, updater's own configuration says "replaceopt AllowRetards AllowMentallyDisadvantagedPeople", so updater replaces comments and values for this option
5) Updater goes through option
AllowRemoteControl, it replaces comments and notices #!keep, so keeps option value as previous default was (even in /etc/defaults - reasons: well if only the user config kept the previous value and the default changed to the brand new value next time around this keep directive will be useless since default and user values differ and user value will be respected anyways. if user removes that directive and default value is changed back to version 1 (as is by user's desire, that protection will be lost, also #!keep can be used by package maintainer for whatever reason - cvs versions for example)
Whenever #!keep is triggered both old and new comments are kept and date of file is appended above each of them (if not already appended)

Finally it places new default into /etc/default
And updates /etc/bar.conf; it will look as follows:

# this is by law
# I don't care about the law
AllowFatChicks No

# now it's stable, say yes here, as it is by law...
AllowTransvestites Yes

# option name changed for political correctness
# You never say yes here
AllowMentallyDisadvantagedPeople No

# 01/01/2003
# this may eventually change to yes
# 02/02/2003
# mike: i think this is secure, i tested it right away when i got that cvs access
# !keep
AllowRemoteControl No

Possible port-specific configuration directives, just an example:
commenttag # face
commenttag // face
commenttag /* embrace */
commenttag { embrace }
commenttag ; face
replaceopt AlowGPL AllowGPL
#the following one should be overridable by global setting with which the user has decided not to let a package #maintainer decide for him, even if not forcing this value can cause breakage
forceoptvalue KernelVersion

subsections yes
sectiontag <option> embrace </option>
sectiontag <option> face
sectiontag { embrace }

Note: no section support in examples, I am thinking about section, subsection support
things get complicated if a subsection name is changed and certain values within are added, since subsections belong to specific section, this will definitely need more port maintainer directives. One tricky one is when software reads options the same whether they are in a specific subsection or global (apache for example)

I can write the framework in C/C++, however, python is the language used in ebuilds so it will take me a bit more time to get used to that. Does anyone like this idea?

[HogRider]

Sounds great mario. There are certain files which should never be undated (fstab), but other config's (which I've never touched) back up considerably.

I'm not a coder, but I'm willing to help. I do understand processes.
_________________
Mike

"Computers are like air conditioners, they stop working properly if you open Windows"
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

[pjp]

You might want to take a look at Updating unmodified config files automatically.

Be sure to note: