Date: Thu, 3 Sep 2009 09:15:47 -0400 From: Wesley Shields <wxs@atarininja.org> To: Yarema <yds@CoolRat.org> Cc: Mel Flynn <mel.flynn+fbsd.ports@mailing.thruhere.net>, John Marshall <john.marshall@riverwillow.com.au>, freebsd-ports@freebsd.org Subject: Re: Dovecot Sieve port switched from CMU Sieve to Dovecot Message-ID: <20090903131546.GA45221@atarininja.org> In-Reply-To: <4A9FB023.7030703@CoolRat.org> References: <20090827131800.191378ee@gumby.homeunix.com> <4A982DC9.7050608@CoolRat.org> <20090829181122.GA22669@atarininja.org> <200909021519.41950.mel.flynn%2Bfbsd.ports@mailing.thruhere.net> <4A9FB023.7030703@CoolRat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090903131546.GA45221>