On Sat, May 22, 2010 at 07:17:29PM +0100, Alan Buxey wrote:
although some would say thats the package people talking - and that the issue is only present because of how package management tools etc work. surely the best way of RPM, APT etc leaving behind all their rubbish/old-files/new-files etc is for them to utilise some revision control system or drop the files into a .special directory, eg .rpmnew for example.
Even if there was no packaging system, you would still have users who aren't excessively pedantic who would leave their own copies of files in the same folder. For example leaving an explicit copy of an old configuration in e.g. ldap-2010-05-23.bak. It still seems best to avoid the greediest match...
moving to a new system where eg module files have a .mod extension and virtual servers have a .vsf extension (virtual server file ;-) ) then any present systems need to have quite a few tweaks to be upgraded from their present situation...
That's why the mods-{available,enabled} idea is IMHO best. All Apache users are used to it, which covers most people anyway, the FR users got used to sites-{available,enabled} already so it's not much of a leap, and the upgrade procedure is simple: mv $confdir/modules $confdir/mods-available mkdir $confdir/mods-enabled cd $confdir/mods-enabled && ln -s ../mods-available/* . That preserves existing functionality to the letter - but it allows people to later disable what they don't want/need easily - just remove some extra symlinks.
you could also argue that the easiest way is to include each file line by line in the radiusd.conf instead of using funky directories and including files wholesale.
This is bad for packaged radiusd.conf's because it requires explicit user intervention into the file contents. The unconditional inclusion of (also packaged) eap.conf is an example of why this is bad - the admin who wants to tweak those settings has to either modify radiusd.conf to comment out the inclusion, or modify eap.conf to adjust the parameters. And either one of those causes the packaging system to notice that the user changed a configuration file upon the next upgrade, and in turn present a possibly confusing choice to the upgrading admin - and that kind of a situation doesn't necessarily end well :) Since this file simply defines the eap module, I don't really see any reason why it should not exist simply as a modules/eap file (or analogous in the future). Same goes for sql.conf, but luckily that one is commented out by default. -- 2. That which causes joy or happiness.