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