Re: mail/dovecot removed

[Greg Troxel <gdt%lexort.com@localhost>]

nia <nia%NetBSD.org@localhost> writes:

> On Fri, Mar 13, 2020 at 07:20:43PM +0100, Edgar Fu? wrote:
>> > State-Changed-Why:
>> > dovecot has been removed from pkgsrc. mail/dovecot2 properly supports quota2.
>> Did I miss a discussion about mail/dovecot removal?
>> 
>> I agree it's long dead upstream, but there's only one known security bug, and I backported the fix from a newer version.
>> 
>> Of course I can keep a copy in my private tree.
>
> It will no longer work because we are now requiring OpenSSL 1.1 everywhere.

@Edgar you did not miss a recent discussion.

Generally we require discussion for removals.  However, in the case of
dovecot there have been discussions every year or two for several years,
with just barely enough people wanting to keep it - perhaps even just
you.  dovecot was last updated in May of 2011.

Nia said it fails with openssl 1.1 and it's clear it isn't going to be
updated.  I know both of those statements to be very true!

So we have been having removals for things that are really really
unmaintained and for which there is a new version or which cannot build
with modern openssl.  These have been without discussion, and as long as
they are such extreme cases that the discussion could not result in
keeping them, I'm just barely ok with that.  As things get to be
something that somebody might fix, I think we need to have the usual
deletion proposal and wait a week.

In your tree, have you been able to build mail/dovecot?  I just
resurrected it and it fails in openssl.

In this case, though, there is the issue that it might build with
gnutls.  But, I just tried that, and that failed to.

Can you actually build it with pkgsrc current (say from 2020-03-11)?



You are welcome to put it in wip (and depend on gnutls, and get rid of
the ssl option, and fix the gnutls option).  That lets you use it, other
people use it, but leaves it out of bulk buildsand means pkgsrc changes
don't have to pay attention to breaking it.

You are also welcome to fork it and make it a maintained upstream, and
then a package in wip would be eligible for hoisting to pkgsrc proper,
but that sounds like a vast amount of work that isn't really sensible
(but your work, not mine, so your call).

Generally in pkgsrc we have to draw the line at unmaintained, unusuable
code, taking into account the upgrade strategy.  I haven't heard any
compelling reason to run dovecot 1 vs 2 other than that 2 is a bit
bigger and perhaps slightly harder to configure.  But it's not really
that big or that hard.