On 24.3.2012, at 3.19, Noel Butler wrote: >> Yes, I was also thinking about that, but it's about removing the dovecot/ >> suffix from other directories as well. That might be something worth doing >> (--without-package-suffix or something?). > it is very easy to have a search path for config file, it shouldn't > take much effort at all to change that to look for the long time default > of /etc/dovecot.conf first, then if not there, look in /etc/dovecot/
Technically it's easy, but the result will be that more people will be confused. I'll get an increase of emails about "I changed dovecot.conf, but nothing happens?!?" My goal is to reduce the number of emails I get, not increase them. > No-one is suggesting putting all the individual conf files in /etc, only > for existence of dovecot.conf itself. So you don't want to remove dovecot/ suffix from all the other dirs (lib, libexec, etc.) only from etc? The only way I can think of how to do that is to add a special option just for it, and more options is generally bad: > Which brings up another question, may I ask why some of the options to > disable some passwd types were removed from build process? Systems that > dont use system password files (amongst other formats) dont need to > build them, that's not a criticism, 'just sayin'. There's also no harm in having that code included. They add no extra library dependencies. The only thing they do is to use a few kilobytes of more disk space, and possibly a few kilobytes of more memory (even that isn't certain). All options just increase the number of combinations that can cause things to go wrong. If I add some code to be compiled optionally, it just adds more combinations that should be tested together to see if the code still even compiles. Previously I've broken SSL code many times by not testing if after changes Dovecot builds without OpenSSL. So the less options there are, the more robust Dovecot is, and the less work I have to do to keep it working when adding new features. So I add an option only when there is a good use case for it and I expect more than one person to use it.
