On 24/01/2026 14:10, Curtis J Blank via dovecot wrote:
I just did a Tumbleweed upgrade. then I had to fix dovecot. No warning that dovecot was going to break what so ever. Below is all the things I had to fix. And then I could not read my email in Thunderbird because you changed:
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u to mail_driver = mbox mail_path = ~/mail mail_inbox_path = /var/spool/mail/%{user}
and the "%u" to "%{user}" was the showstopper.
What a crock of BS! I spent 3 hours determining the problem and then fixing dovecot because you decided to make major changes for no good reason. It worked just fine the way it was. You could have automated the changes by providing a utility that would make the changes the first time it started up after the upgrade.
Hi Curtis
I understand the unexpected difficulty that you had to go through when you found the new version of Dovecot upgraded in your distro upgrade. But it has to be said that the 2.4 version has been a long time coming and is now at 2.4.2 and you can say many things, but the incompatible changes have been well known and publicized for a very long time now, I think probably years rather than months. If you're using Dovecot it would be best to keep an eye on announcements. Even if you hadn't noticed it, this didn't just come out of the blue.
I personally am still running the previous version on Fedora 42 and since the upgrade to 43 includes the new 2.4 I have made my own 2.3 rpms for Fedora 43 so that I can keep running it and then do the config conversion calmly and in a test environment before doing it for real, while still getting the new version of the distro. That strategy itself is not without risk though.
I can't blame distro packagers either. Some people are going to want the newest version, some people are going to be reticent about breaking their configurations and about the stabilization of the new version. You can't reallly please everyone.
The need for a configuration upgrade utility was probably clear to most people, but if it hasn't been done I think it is partly due to the difficultly of that task. it would have to cover many configuration parameters, not just the ones that you had to change in your case. Also some incompatible changes are not managed just through configuration. Depending on what features you currently use there could be some decisions to be taken too. I started to do some config migrations already on the previous installation for some of those features that were being deprecated in the new version just to hopefully smooth the final migration.
My guess is that so far no one has thought that it would be quicker to write a configuration utility than actually do the changes relevant to their own configuration. But that is the beauty of open source software. If you see a gap for something and you have the skills you can contribute something back and improve things for other people.
John