Hi Antoine, Stuart, All,
Stuart, thanks for updating wslay.
Antoine, thanks for your feedback.
The diff from my first mail is to be applied to the port when the upstream
publishes the new minor release in the 3.2 branch, which will be 3.2.5 and I
guess it should be released in a week.
The diff adjusts the port to accommodate all the cross-platform improvements
that we incorporated since the last 3.2.4 release (it mostly removes the no more
needed patches and slightly adjusts the PLIST to accommodate some minor
CONFIGURE_ARGS changes).
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.
I've read the docs [1], [2], [3], [4] and [5] (not sure if there are other
places documenting it), but I can't find where the final flavor combinations are
defined.
E.g. in the vim port there are these flavors defined:
35:FLAVORS+= gtk2 gtk3 no_x11
37:FLAVORS+= lua perl python python3 ruby
But I can't find how they end up being those flavor options available to the
users for install via pkg_add:
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
Why, for example, lua is never combined with perl-python-ruby, etc. I don't see
where this restriction is defined.
[3] says: The port maintainer will set FLAVORS to be the list of possible
options in the Makefile. When building the port, the package builder will set
FLAVOR='option1 option2...' to build a specific flavor of the port.
Does that mean that someone responsible for building the packages will set the
combinations manually and the maintainer doesn't have control over the versions
built? And if this is the case, what's the process of communicating to the build
team what flavor combinations make sense for the port?
I'm planning to define the following flavors for cyrus-imapd:
* an empty flavor (the default) with the options like it is now (with my
initial diff applied that makes minor adjustments to the CONFIGURE_ARGS);
* http: a http-enabled build which includes *DAV (WebDAV, CalDAV & CardDAV)
functionality as well as the new IMAP replacement protocol JMAP;
* replication: murder, replication and backup functionality;
They could be combined freely:
empty
http
replication
http-replication
I am using just the http flavor, so not sure if other combinations make sense to
the users (e.g. clamav integration, different storage options, databases, etc.).
Maybe we could enable just those listed above (e.g. the empty one, http,
replication and http-replication) and then ask users for feedback (I'm willing
to process all the feedback and adapt the port accordingly).
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.
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.
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].
Regards,
Anatoli
[1] https://man.openbsd.org/ports.7#FLAVORS
[2] https://www.openbsd.org/faq/ports/ports.html#PortsFlavors
[3] https://man.openbsd.org/bsd.port.mk.5#FLAVORS_AND_MULTI_PACKAGES
[4] https://www.openbsd.org/faq/ports/guide.html
[5] https://man.openbsd.org/pkgpath.7
[6] https://github.com/cyrusimap/cyrus-imapd/pull/3262#issuecomment-723680233
On 19/11/20 09:16, Antoine Jacoutot wrote:
> On Wed, Nov 18, 2020 at 03:44:35PM -0300, Anatoli wrote:
>> Hi Antoine, all.
>>
>> For some months I was updating the cyrus-imapd port, upstreaming the
>> upstreamable patches and working with the upstream to improve additional
>> features of the port as follows.
>
> Hi Anatoli.
>
> That's awesome work, thanks for taking the time to work with upstream on this.
> I must say that I manage so many ports that I cannot find the time /
> motivation
> to work will all upstreams, all with a different contribution process etc.
>
> What's your next step on this?
> Wait until a new stable release is out and then we can update the port with
> your changes?
>
> Thanks again.
>
