RFE: Add presets for with/without combinations

[nazunalika]

It should be possible to use build presets for with/without combinations. For example, to do a "plus" build for Thunderbird, we need to have with rlplus, which will provide a thunderbird plus build. This would also allow us to turn on openldap-server builds without modifying the spec file.

[nazunalika]

We've received requests for a plus version of thunderbird. Resolving this will help with this request.

[mstg]

https://git.rockylinux.org/rocky/peridot-rocky/-/blob/r9/extraoptions.cfg#L5
So we do support with/without, but not as a preset per-se. Enabling/disabling that option requires a catalog sync each time which is tedious.
If keeping the with option enabled won't make it RHEL incompatible besides emitting new artifacts, then it should be good to go, otherwise we can look into the preset option and prioritize it.

[nazunalika]

The issue is with thunderbird in this example is it would make it completely incompatible with upstream. We patch it to allow the ability to turn on rlplus (which turns on pgp and librnp), default is that it builds just like upstream does. Thunderbird for example is built twice for Rocky Linux 8 in koji. One is using default settings, the other the rlplus conditional is turned on.

This is because the first one is compatible with upstream and the second turns on a feature that spits out additional packages and both are then depending on each other. That incompatible version is then sent off into plus.

The only alternative I tried to think about was having thunderbird-plus in staging/src but keep the thunderbird name for the packages that come out (and it'll keep .plus in the dist tag). But I don't think srpmproc would be a fan of this (admittedly kind of poor) idea.

[nazunalika]

Another idea could be maybe having a separate "plus" project to get around this, but maybe that's too much? Especially since openldap is one full build for example, we just turn on a switch that Red Hat turns off.

[mstg]

Ah, I see. Due to the nature of the flag, supporting variants/presets (aka multiple instance of same package with different flags) seems like the most logical choice. I can't imagine supporting that scenario would require too much change considering how we keep internal state at the moment. Let's plan this out and get back to it.