Dovecot Sieve port switched from CMU Sieve to Dovecot

Yarema yds at CoolRat.org
Thu Sep 3 12:10:53 UTC 2009


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

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.. :)

-- 
Yarema


More information about the freebsd-ports mailing list