On Mon, 25 Aug 2003, [iso-8859-2] Ond�ej Sur� wrote: >Well, I only think it is not consistent, to install configfile under two >different file names. Maybe you could check for existance of config >file and print some text only if format of config file changes (and you >can detect it). If I compare it to nsd (nameserver from NLnet Labs), >then they install all config files as samples: > $(INSTALL_DATA) nsdc.conf.sample $(configfile).sample > $(INSTALL_DATA) nsd.zones.sample $(zonesfile).sample >I think that first time installers need to setup supervise or other run >script, so cp bincimap.conf.sample bincimap.conf is not big deal for >them either. But you are upstream author ;-), so choose as you think it >is wise.
"make install" for me resembles that of doing a "rpm -i" with packages, or "apt-get" or "deb". rpm takes care of this problem for us by detecting changes to the files. If the old file is unchanged, it is silently replaced. It the old file is changed and the new is the same as the original old, then the file is untouched. If the new is changed, it is saved as ".rpmnew" so "bincimap.conf.rpmnew". A warning is then displayed to the user. So rpm does not follow the idea of always installing the same files - it changes the names depending on the situation. What do you think of RPM's solution? >In Debian there is quite clever way to install new config files, package >knows if config file was changed and install new config without asking >you only if it was not changed. If you changed it, installation asks >you if you want to keep old file (and place new config as *.dpkg-dist or >something like that) or replace with new (and copy old config as >*.dpkg-old). This is fine, but I think that it is too complicated to do >for single package. People how knows what they are doing don't need >such stuff. People how are clueless, should use package, which should >handle it all ;-). I guess Debian and RPM use the same system, but RPM has a non-interactive version which works for most people. I'd like "make install" to work like an alternative to the packaging systems, for those who wish to use upstream Binc IMAP. I want to be consistent, but at the same time not overwrite config files. I also want the number of steps in the installations procedure down to as-few-as-possible, and with as little interaction as possible. How can we combine the ideas of your preferred alternatives with my preferences? Andy :-) -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something | than to do it poorly."
