I'm integrating Sieve (the new one) and ManageSieve into wip/dovecot. Currently, this works as dovecot options because dovecot must be built before sieve can be configured and sieve must be built before managesieve can be configured/built. Now, the question arose what the long-term solution (in pkgsrc) should be. To my understanding, with dovecot 2.0, ManageSieve will no longer need to patch dovecot. But what about both Sieve and ManageSieve depending on doevcot sources in order to build (or on libraries dovecot only builds internally)? The preferred way (for pkgsrc) would be if both Sieve and ManageSieve could be built as stand-alone packages and not needing a dovecot source tree to build. What's the long-term plan for Sieve/ManageSieve in this respect? The pkgsrc infrastructure (intentionally) doesn't like a package depending on anothers package working directory in order to build. So with these cross-dependencies, the only pkgsrc ways to go would be either to build it all as one package with options (that's what I currently do) or extract, patch, configure and build dovecot inside a sieve package.
On Thu, Jun 25, 2009 at 03:43:09PM +0200, Edgar Fu? wrote:> I'm integrating Sieve (the new one) and ManageSieve into wip/dovecot. > > Currently, this works as dovecot options because dovecot must be built > before sieve can be configured and sieve must be built before managesieve > can be configured/built. > > Now, the question arose what the long-term solution (in pkgsrc) should > be. > To my understanding, with dovecot 2.0, ManageSieve will no longer need to > patch dovecot. But what about both Sieve and ManageSieve depending on > doevcot sources in order to build (or on libraries dovecot only builds > internally)? > > The preferred way (for pkgsrc) would be if both Sieve and ManageSieve > could be built as stand-alone packages and not needing a dovecot source > tree to build. What's the long-term plan for Sieve/ManageSieve in this > respect? The pkgsrc infrastructure (intentionally) doesn't like a package > depending on anothers package working directory in order to build. So > with these cross-dependencies, the only pkgsrc ways to go would be either > to build it all as one package with options (that's what I currently do) > or extract, patch, configure and build dovecot inside a sieve package.See also http://www.dovecot.org/list/dovecot/2007-August/024504.html which enabled pkgsrc to build the dovecot-sieve plugin (the old one) against an installed dovecot instance with only liblib.a installed additionally. Geert -- Geert Hendrickx -=- ghen at telenet.be -=- PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
On Thu, 2009-06-25 at 15:43 +0200, Edgar Fu? wrote:> The preferred way (for pkgsrc) would be if both Sieve and ManageSieve > could be built as stand-alone packages and not needing a dovecot > source tree to build. What's the long-term plan for Sieve/ManageSieve > in this respect? The pkgsrc infrastructure (intentionally) doesn't > like a package depending on anothers package working directory in > order to build. So with these cross-dependencies, the only pkgsrc ways > to go would be either to build it all as one package with options > (that's what I currently do) or extract, patch, configure and build > dovecot inside a sieve package.Dovecot v2.0 installs shared libraries, which are used by Dovecot binaries and can also be used for building Sieve binaries. v2.0 isn't anywhere close to release, but you could already try and see if it provides everything that's necessary to do a clean pkgsrc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20090627/8368f9ce/attachment-0002.bin>