Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 03 Sep 2009 08:01:39 -0400
From:      Yarema <yds@CoolRat.org>
To:        Mel Flynn <mel.flynn+fbsd.ports@mailing.thruhere.net>
Cc:        Wesley Shields <wxs@freebsd.org>, John Marshall <john.marshall@riverwillow.com.au>, freebsd-ports@freebsd.org
Subject:   Re: Dovecot Sieve port switched from CMU Sieve to Dovecot
Message-ID:  <4A9FB023.7030703@CoolRat.org>
In-Reply-To: <200909021519.41950.mel.flynn%2Bfbsd.ports@mailing.thruhere.net>
References:  <20090827131800.191378ee@gumby.homeunix.com> <4A982DC9.7050608@CoolRat.org> <20090829181122.GA22669@atarininja.org> <200909021519.41950.mel.flynn%2Bfbsd.ports@mailing.thruhere.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A9FB023.7030703>