Stuart,
Thanks a lot for the explanation! Much appreciated!
cyrus-imapd project is mostly modular (e.g. if it's built with --enable-http,
there would be additional binary httpd), but there are also some elements that
hold the compilation information, like cyr_buildinfo [1] which returns the
details about the components, dependencies, etc. that were activated or not
during the build:
$ cyr_buildinfo
{
"component": {
"event_notification": false,
"gssapi": false,
"autocreate": true,
"idled": true,
"httpd": true,
"kerberos_v4": false,
"murder": false,
"nntpd": false,
"replication": false,
"sieve": true,
"calalarmd": false,
"objectstore": false,
"backup": false
},
"dependency": {
"ldap": false,
"openssl": true,
"pcre": true,
"clamav": false
},
"database": {
"mysql": false,
"pgsql": false,
"sqlite": true,
"lmdb": false
},
"search": {
"squat": false,
"sphinx": false,
"xapian": false,
"xapian_flavor": "none"
},
"hardware": {
"sse42": true
}
}
I've asked [2] the devs about the extent of the modificaions that the same files
experience with different options. They are all affected by config.h include
holding the configuration options.
There's also a libcyrus library that has all the API definitions for the
requested functionality that builds conditionally. Part of the reply from a dev
from [2]:
> If you've built it with everything included, then there is no particular
> advantage to packaging up subsets of that. You might think "we can avoid
> bloat by excluding the features we don't need", but in this case all the APIs
> to support those features would still be in libcyrus, you would just be
> missing binaries. You could have achieved the same effect by just not running
> those services in cyrus.conf
I guess it would be more appropriate to proceed with flavors.
I was thinking about actually defining a number of flavors (basically for most
components and dependencies as returned by cyr_buildinfo), but to build only 4
combinations as part of the build infrastructure (the most clear use-cases), so
the rest of possible combinations could be activated by the users in the ports.
Does that sound good?
And if I understood it correctly, I'd have to use PFRAGs and %%flavor%% in PLIST
to define the build differences for each flavor, right?
Regards,
Anatoli
[1]
https://www.cyrusimap.org/imap/reference/manpages/systemcommands/cyr_buildinfo.html
[2]
https://cyrus.topicbox.com/groups/devel/T5acbcb9536dc47c3/cyrus-imapd-packaging-flavors-variations
On 22/11/20 10:53, Stuart Henderson wrote:
> On 2020/11/22 00:27, Anatoli wrote:
>> Then, I'm working now on the flavored version of the port, and my idea is to
>> apply it as soon as the new minor version is published (or maybe even before
>> this so not to deal with the REVISION) but this is my first time working with
>> ports, so I have no experience with the process and I have a couple of
>> questions
>> about some aspects of flavors definition.
>
> Is the build "modular"? That is, do the build options just have it build
> additional features in separate files (.so modules etc), or do they change
> the main binaries too?
>
> For builds which are modular, generally we do a single build and split
> the various files into subpackages. See for example PHP, Asterisk,
> Dovecot. MULTI_PACKAGES is defined with a list of subpackage names,
> the port is built once, packages are created for each subpackage
> using the relevant "PLIST-sub" file.
>
> (Heading off something you will see in some of these ports - there are
> "no_*" pseudo-flavours in some of these which are an optimization to
> reduce build dependencies for people building themselves rather than
> using packages - ignore these initially, they would be something to add
> later, if at all).
>
>> 1: vim-8.2.1805p0-gtk2
>> 2: vim-8.2.1805p0-gtk2-lua
>> 3: vim-8.2.1805p0-gtk2-perl-python-ruby
>> 4: vim-8.2.1805p0-gtk2-perl-python3-ruby
>> 5: vim-8.2.1805p0-gtk3
>> 6: vim-8.2.1805p0-gtk3-lua
>> 7: vim-8.2.1805p0-gtk3-perl-python-ruby
>> 8: vim-8.2.1805p0-gtk3-perl-python3-ruby
>> 9: vim-8.2.1805p0-no_x11-lua
>> 10: vim-8.2.1805p0-no_x11
>> 11: vim-8.2.1805p0-no_x11-perl-python-ruby
>> 12: vim-8.2.1805p0-no_x11-perl-python3-ruby
>> 13: vim-8.2.1805p0-no_x11-python
>> 14: vim-8.2.1805p0-no_x11-python3
>> 15: vim-8.2.1805p0-no_x11-ruby
>
> Solène explained how this list is defined. vim (and some other things
> like mutt) are just "either/or", so there's no alternative to building
> it multiple times. But it's better to avoid building what is essentially
> the same port 15 times if possible :)
>
>> Then I have some other questions like what does 'M'(option1) and 'L' mean in
>> places like: .if ${FLAVOR:Moption1} or .if ${FLAVOR:L:Mcrypto}? I've seen
>> other
>> letters (F) being used in a similar way, but haven't seen anything in the
>> docs
>> explaining what they mean.
>
> :L is lowercase, :M is match, these are documented in make(1), "Each
> modifier begins with a colon and [...]"
>
> F isn't in this list, is that just a variable defined in a Makefile
> somewhere?
>
>> How PLIST, DESCR files should be prepared and what's the purpose of the
>> PFRAG.xx
>> files? Looks like PLIST and DESCR could have versions for multi-packages, but
>> not for the flavors, though PFRAG files appear to be flavorable, but not sure
>> how exactly and what content/format they should have.
>
> PFRAGs handle files which exist only in certain flavours of the port.
> If a port has a flavour "foo" and PLIST has a %%foo%% entry, PFRAG.foo
> is inserted into the PLIST at that point only when the build is done using
> that flavour. Likewise if there is a !%%foo%%, PFRAG.no-foo is inserted
> for all flavours *except* foo.
>
> (This mechanism can also handle the case where there are differences
> in the file list between different machine archs by defining a variable
> for pkg_create - you won't need it here but for an example see how
> PKG_ARGS is set in lang/go-bootstrap).
>
>> So how should I update the PLIST in order to accommodate flavor differences
>> if
>> it's a single version for all flavors? And should I create other files
>> (PFRAG)?
>>
>>
>> And a side note: this port probably should NOT be built on 32-bit archs due
>> to
>> the devs supposition that all time-related structures are 64-bit and there
>> could
>> be security implications if this is not the case (signedness and int
>> overflow).
>> Here's a discussion about this without a definitive conclusion [6].
>
> This only relates to the size of time_t, not the whole architecture.
> NetBSD changed time_t to 64-bit on all architectures in 6.0 (2012),
> OpenBSD did the same in 5.5 (2014). Linux now has support too (in 5.6,
> this year) but maintained the old ABI and with the long term
> binary/library compatibility I guess it will be quite some time before
> software actually running on most people's machines will be rebuilt for
> this. Looks like FreeBSD still uses 32-bit on i386 but 64-bit on others
> (including non-i386 32-bit).
>
> We still run into bugs in application software that assumes time_t is
> "long", especially in format strings (the standard approach we take in
> ports when patching things is to use long long format strings, and cast
> the variable to long long so that the patch can be fed upstream without
> breaking things on other OS). Presumably as Cyrus devs are aware of
> this they will be taking reasonable care!
>
