Feature flags

[voxik]

I wonder what is the plan leveraging the feature flags using %bcond_with?

[sgallagher]

@contyk Was going to look into this after F34 was out the door, so now seems like the right time to restart that discussion.

[sgallagher]

@contyk ping

[contyk]

Glad to see there is some interest in this.

I got some interesting feedback for the original proposal; mostly positive for the idea itself, some ideas for the implementation. The next steps aren't super clear but I'd like the second iteration to address a few things:

1. Make it easier for people to define package-specific flags, preferrably directly in their packages. One possibility to do this is would be dropping files in some specific directory the macros would read them from before evaluating. It still needs to be possible to override thsoe by the distribution, per package, and by users, otherwise it defeats the purpose somewhat.
2. Module integration through direct macro definitions was horrifying but there's currently no other way to do that. Perhaps a modularity RFE would be in order.
3. The reliance on the %name macro availability had some shortcomings as the package name can be defined at a later stage. I don't currently have an idea for a solution here.
4. Polish the nomenclature to avoid confusion where possible, especially with respect to the "local" flags.

But yes, I'd like to come up with something in the upcoming months.

I want this to provide the same level of flexibility Gentoo USE flags have, with global "release" definitions, package-specific definitions or overrides, potential additional overrides for both for spins or similar, and local overrides for both for developers and end users who build their own packages locally. And it needs to be reliable, easy to use, compatible and not all that different from bconds.

[voxik]

original proposal

Was it something tangible?

I think that ATM, it would be enough if the feature flags were some macros.features file with list of:

# This can optionally disable support of feature A in package foo.
with_featureA 1
# This enables to remove package B from buildroot. If B is in buildroot, then that is error which should be fixed.
with_featureB 0

This is pretty basic. It could be pulled in via redhat_rpm_config and that would be it.

[contyk]

It was, yes: https://gist.github.com/contyk/0aaaaf0585c57976ca18a293b3566408
It also included a COPR package with a sample implementation.

[contyk]

Discussion: https://lists.fedoraproject.org/archives/list/[email protected]/thread/4DWDPKYBOXTCGKXJTOIVPO34A5BTOE3T/

[yselkowitz]

So far, all use of feature flags in ELN have been at the specfile level, not globally. Is there still something here that needs work?

[voxik]

Yes, I think it would be nice if feature flags worked globally. There are not feature flags in use as far as I know, but they could be useful to e.g. reduce content of Buildroot. There are e.g. a lot of -doc subpackages, or -javadoc subpackages, various language bindings, etc.

[yselkowitz]

While it is possible to use koji tag options to set feature flags for that tag (e.g. we do this for flatpak builds), it seems very unlikely that we could implement this practically in ELN. Not only do we currently build ELN and ELN Extras in the same build tag (although that has its own issues tbh), even within ELN AFAICS we can't just say "never build docs" or "never build perl (or any other particular language) bindings". Doing so also makes it somewhat opaque as to why a particular subpackage/feature is enabled in one build and disabled in another. Once you're touching the spec file anyway to implement a (consistently named) feature flag, you might as well just put the preference in the spec file.

Furthermore, it's not necessarily always worth the trouble to disable a particular subpackage in the build when it doesn't add any net new dependencies, and there really isn't harm in docs and other unused subpackages to remain in the buildroot. (Minimizing the buildroot should be primarily focused on things that might be used outside of RHEL, particularly in EPEL, and minimizing the need for needless rebuilds.)

Therefore, I would need a compelling argument and example here.

[voxik]

Furthermore, it's not necessarily always worth the trouble to disable a particular subpackage in the build when it doesn't add any net new dependencies

This specifically is questionable, as we learned during late cycle C10S updates of Perl 5.40 and java-21-openjdk. During such update, it is necessary to make sure those subpackages still works and are not FTBFS. If there were no such subpackages, we would not need to care.

Admittedly, I don't remember the specific context, why I have opened this request, but given the 3 years anniversary, it must have been discussion of similar kind.

And BTW I support having feature flags, but I don't like having some RHEL / EPEL and similar conditions in spec file. These are always wrong and not testable in Fedora context.

[yselkowitz]

Furthermore, it's not necessarily always worth the trouble to disable a particular subpackage in the build when it doesn't add any net new dependencies

This specifically is questionable, as we learned during late cycle C10S updates of Perl 5.40 and java-21-openjdk. During such update, it is necessary to make sure those subpackages still works and are not FTBFS. If there were no such subpackages, we would not need to care.

In those particular cases I agree, and they fall under the "minimizing the need for needless rebuilds" condition.

Admittedly, I don't remember the specific context, why I have opened this request, but given the 3 years anniversary, it must have been discussion of similar kind.

That's what I'm trying to ascertain, because so far I'm not sure what is actionable here.

And BTW I support having feature flags, but I don't like having some RHEL / EPEL and similar conditions in spec file. These are always wrong and not testable in Fedora context.

Not sure how they're "always wrong" but they are testable -- that's exactly what ELN is for.

[voxik]

Admittedly, I don't remember the specific context, why I have opened this request, but given the 3 years anniversary, it must have been discussion of similar kind.

That's what I'm trying to ascertain, because so far I'm not sure what is actionable here.

Just googling a bit, isn't this the "original proposal" mentioned by @contyk?

https://lists.fedoraproject.org/archives/list/[email protected]/thread/4DWDPKYBOXTCGKXJTOIVPO34A5BTOE3T/

And BTW I support having feature flags, but I don't like having some RHEL / EPEL and similar conditions in spec file. These are always wrong and not testable in Fedora context.

Not sure how they're "always wrong" but they are testable -- that's exactly what ELN is for.

1. During past few months, I have received a few PRs with RHEL conditions, but AFAIR, we were always able to remove them.
2. During Fedora development, RHEL flags should never be considered. RHEL in 3 years will be different. It is not even given that such component will be part of RHEL.

But having feature flag such as "don't produce -doc subpackage" is orthogonal to RHEL, it is valuable on itself, maybe for minimal container purposes. Having "don't produce -java binding" is useful flag on itself, trying to provide system without Java.

[voxik]

Admittedly, I don't remember the specific context, why I have opened this request, but given the 3 years anniversary, it must have been discussion of similar kind.

That's what I'm trying to ascertain, because so far I'm not sure what is actionable here.

Just googling a bit, isn't this the "original proposal" mentioned by @contyk?

https://lists.fedoraproject.org/archives/list/[email protected]/thread/4DWDPKYBOXTCGKXJTOIVPO34A5BTOE3T/

Feature flags are also mentioned here:

https://pagure.io/fesco/issue/2365#comment-639889