Dovecot Sieve port switched from CMU Sieve to Dovecot

[Wesley Shields]

On Thu, Sep 03, 2009 at 08:01:39AM -0400, Yarema wrote:
> Mel Flynn wrote:
> > On Saturday 29 August 2009 20:11:22 Wesley Shields wrote:
> >> On Fri, Aug 28, 2009 at 03:19:37PM -0400, Yarema wrote:
> > 
> >>> I was previously overruled by a committer when I filed a PR to default
> >>> ManageSieve to ON.  IIRC, POLA was sited as the reason.  I'm still of
> >>> the opinion that the ManageSieve patch to the main dovecot port should
> >>> default to ON for the following reasons:
> >>>
> >>> - with the ManageSieve patch built into the package it becomes possible
> >>> for users of binary packages to just install the dovecot-sieve and
> >>> dovecot-managesieve ports and have them work.  As it stands now anyone
> >>> who wants to use ManageSieve has to build the dovecot port from source.
> >>>   So it doesn't even make sense to have a binary package of
> >>> dovecot-managesieve unless the ManageSieve patch is built into the
> >>> dovecot package by default as well.
> >>>
> >>> - the ManageSieve patch does not add much bulk to the package.  Those
> >>> who do not use ManageSieve can simply ignore it or if they build from
> >>> source can disable it.  Either way from the perspective of those who do
> >>> not use ManageSieve nothing really changes (thus POLA is not violated).
> >>>
> >>> - and finally there would be fewer broken PRs filed without the distinfo
> >>> for the ManageSieve patch included.
> >>>
> >>> In my opinion it seems not having the binary dovecot-managesieve package
> >>> "just work" is more of a POLA violation than having an extra
> >>> README.managesieve and related dovecot.conf sections installed by
> >>> default in the main dovecot port.
> >> I have no problems marking that option as on by default since it will
> >> mean that the managesieve port can be usefully packaged, while not
> >> bloating the port at all.
> > To further this issue in the "right" direction, I've investigated the bloat, 
> > using a slave port:
> > PORTNAME=       dovecot
> > PKGNAMESUFFIX=  -withsieve
> > CATEGORIES=     mail ipv6
> > MASTERDIR=      ${.CURDIR}/../../mail/dovecot
> > CONFLICTS=      dovecot-1*
> > 
> > .include "${MASTERDIR}/Makefile"
> > .if defined(WITHOUT_MANAGESIEVE)
> > .undef WITHOUT_MANAGESIEVE
> > .endif
> > WITH_MANAGESIEVE=       yes
> > 
> > Result:
> > -rw-r--r--  1 root  wheel  2626479 Sep  2 05:05 dovecot-1.2.4.tbz
> > -rw-r--r--  1 root  wheel  2626719 Sep  2 05:04 dovecot-withsieve-1.2.4.tbz
> > 
> > I think more bytes have been wasted on discussing this, then it adds to the 
> > port. Also, I've left it off, thinking "I'll add this later or just add the 
> > package", because the OPTION framework does not really have enough room to 
> > specify "You have to tick this option to ON if you want to be able to add 
> > dovecot-managesieve port later", so yes, POLA was violated by not having it on 
> > by default and the description should probably read something like "Set to off 
> > if you never want managesieve support".
> 
> OK then, Wesley, would you mind defaulting the MANAGESIEVE option to 
> "on" and closing PR/138300?  Which is definitely approved, though we'll 
> most likely have to remove this new patch once it's rolled into the next 
> release upstream. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/138300

The patch from ports/138300 will be committed today, along with
defaulting MANAGESIEVE to on.

> I don't believe we need to bump PORTREVISION for either of these changes 
> since it only affects GSSAPI users and/or binary package users.  But if 
> you feel PORTREVISION ought to be bumped up, then so be it.  I can roll 
> a new patch set if need be and tack it on to the above mentioned PR or 
> file a new one.  But as Mel puts it we're using up more bytes in this 
> thread than is gonna end up in the port after all is said and done.. :)

PORTREVISION will be bumped because it does change the default package
and fixes a bug.

-- WXS