Follow-up suggestion: Clone port dovecot2 to a new port dovecot1 now
Whenever dovecot major release 3 appears: Clone the existing dovecot to new port dovecot2 Update dovecot port to dovecot 3 Is there a mechanism in MacPorts to block automatic update activations when new versions of software require a different configuration and automatic conversion is not possible? Should there be one? > On 22 Feb 2020, at 12:41, Gerben Wierda <gerben.wie...@rna.nl> wrote: > > port dovecot is now installing dovecot 2 > port dovecot2 is now installing dovecot 1 > > The change breaks ‘port update outdated’ as the existence of a dovecot2 > install will prevent the installation of dovecot which now has become a > dependency for other ports instead of dovecot2. dovecot2-sive is likewise > replaced by dovecot-sieve with identical issues. > > The only luck I have now is that the update failed so my existing dovecot2 is > still running and I can thus I can still read mail (including replies to > this). > > Yes, making sure that the port dovecot installs dovecot 2 (current) is > cleaner (letting port dovecot2 install dovecot 1 is bad). But is that worth > this mess? Instead of a nice and simple update, I have (unexpectedly, if I > had known I could have prepared) to figure out the new setup, variants, etc. > And given that the upgrade failed halfway, I have a messed up MacPorts > landscape and I (unexpectedly) have to spend (unplanned) time on this. > Spending time on it is not the problem. Unexpected, because of a strictly > sproken unnecessary cosmetic change, is. > > G