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!
