Configuring cyrus-imapd for compilation

Patrick Goetz pgoetz at mail.utexas.edu
Wed Mar 13 11:24:01 EDT 2019


Thanks, that helps.  A couple of follow up questions:

I found this comment in the documentation for compiling cyrus-imapd:

     MariaDB or MySQL development headers, to allow Cyrus IMAP to use
     it as the backend for its databases.

     Configure option: --with-mysql, --with-mysql-incdir, 
--with-mysql-libdir


Does this mean you can't use virtual email domains unless the 
executables are compiled with these options, or is this just about 
putting the cyrus-imap metadata into a database rather than keeping it 
in the mail folders?

Second question: There are still a lot of current 2.x users out there, 
so there is some utility in keeping a 2.5.x package around, assuming I 
can still get it to work on an up to date Arch system (a recent upgrade 
broke my cyrus 2.5.10 install).

Can I still find instructions for compiling 2.5.x somewhere?  I need to 
go over the build options in the PKGBUILD for this release, as I'm not 
convinced they include everything (for example, there is no mention of 
the mysql options mentioned above.)



On 3/12/19 11:45 AM, Ken Murchison wrote:
> I don't see a downside to have one monolithic package.  I think its 
> easier for an admin to have everything available to them in one package 
> rather than having to go find the correct package for the optional piece 
> they are looking for.  But that's just me.
> 
> 
> 
> On 3/12/19 12:39 PM, Patrick Goetz wrote:
>> I'm finally getting around to updating the Arch linux cyrus-imapd 
>> package, and have a question.
>>
>> Looking through the configuration options, it looks like there are a 
>> number of functionality critical decisions to be made:
>>
>>
>> CalDAV and CardDAV
>>
>>     ./configure --enable-http --enable-calalarmd
>>
>> Murder
>>
>>     `./configure --enable-murder
>>
>> Replication
>>
>>     `./configure --enable-replication
>>
>>
>> The vast majority of cyrus admins are not going to need a Murder or 
>> Replication, but when you need it, you need it.
>>
>> The issue is the Arch build system is based on using a single PKGBUILD 
>> file (which includes the configuration options) and one of the design 
>> principles is the outcome of building a binary package from a PKGBUILD 
>> should be deterministic; i.e. "A PKGBUILD should never be interactive. 
>> This is a rule that should never be broken."
>>
>> So, my options are to create a single package configured for every 
>> possible use case, or to create multiple packages with different 
>> combinations of functionality, which suffers from something of a 
>> combinatorial explosion problem.
>>
>> So, question, given that none of the configuration options appear to 
>> be mutually exclusive:  what are the downsides of compiling cyrus with 
>> everything, including the kitchen sink?  That appears to have been the 
>> original packaging philosophy for the 2.5.x version of the package.
>>
>> Second question.  Quoting again from the documentation for 3.0.8:
>>
>>     MariaDB or MySQL development headers, to allow Cyrus IMAP to use
>>     it as the backend for its databases.
>>
>>     Configure option: --with-mysql, --with-mysql-incdir, 
>> --with-mysql-libdir
>>
>>
>> The 2.5.x package did not include any configuration flags for mysql 
>> support.  Does this mean the older package would not have worked with 
>> mysql (I've never tried using this, so can't confirm), or does it mean 
>> that this was previously a default configuration option in 2.5.x?
>> ----
>> Cyrus Home Page: http://www.cyrusimap.org/
>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>> To Unsubscribe:
>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
> 
> 
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
> 


More information about the Info-cyrus mailing list