What should I do when I add a new config parameter to config file of my package?

Question

I am dealing with making some packages of some projects.

Assume I have a config file like that in my project.

name=foo
mail=foo@foo.com

After installation user edits config file with his/her information.

name=user
mail=user@somedomain.com

When a update comes, for the purpose of not ruin the users config file, I do not replace conf file with new ones as all packages should do.

There is no problem up to this point.

What if I add a new parameter to my config file? For example,

name=foo
mail=foo@foo.com
age=23 

If I replace config file with new one, user will lost its settings. If I don't, my new parameter could not be used. I wonder what is the general procedures for this conditions? My question is valid no matter what package types it is (ie rpm, deb or tbz).

Answer 1

I'm not sure I see the problem. As long as the software can handle the absence of the field in the config file (ie, use a reasonable default), then there is no difference in the two scenarios you describe. If you software cannot handle the absence of the field, I would argue that is a bug.

Answer 2

@William Pursell: Just because you don't see the problem, that does not mean that there isn't a problem.

This definitively is a problem and it has plagued me since I maintain deb packages. For example: many configuration files contain commented configuration items and other comments that the package user is supposed to read and understand before applying his configuration changes. If, in the normal course of software development, there are new configuration items, new default values, or different semantics to existing ones, the comments have to be adapted. This is the package maintainer's job. But at the same time, the package must not mess with the configuration changes already applied by the user.

When I do this in Debian/Ubuntu, the package user is confronted with this intimidating question:

Configuration file `/etc/...'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** ... (Y/I/N/O/D/Z) [default=N] ?

for every single file. That is, for some package upgrades, the user has to type yes/no/maybe :-) many times, every time. Fact is that the package user usually does not know what this is all about. She has to dig into the files, diff versions, and do some guessing in order to figure out a reasonable answer. An answer, by the way, that the package maintainer could have made already, if the packaging system would allow it.

I recognize that there may not exist a general solution to this problem. But I'd love to hear how other package maintainers cope with the situation.