For bootstrapping (e.g. new compiler releases, or populating a new Enterprise Linux branch for EPEL or ELN), it is often necessary to first disable non-critical parts of a package, typically documentation (which might require many additional packages to build) and tests (to break circular dependencies)
Rather than doing this in an ad-hoc way that might differ from package to package, could we have this added to the packaging guidelines as a recommended best practice?
(adding meeting tag since it was requested during the ELN meeting that we talk about this soon-ish)
Metadata Update from @decathorpe: - Issue tagged with: meeting
See also https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/443LZIX4XLZL6NMF3M7HAGHKPNA4TRYN/ where we tried this and failed.
Whether packages add conditionals for running tests or not (which is what it sounds like the mailing list discussion devolved into), it would be great to have a recommendation for those that do.
For example, the Packaging Guidelines could recommend using %bcond check 1 syntax for this purpose in the Fedora packaging Guidelines, but mention that this is not available everywhere yet and document %bcond_without check / %bcond_with check as a fallback for older Fedora releases and RHEL / EPEL.
%bcond check 1
%bcond_without check
%bcond_with check
Whether to use check or tests is bikeshedding territory, but for me, I'd overwhelmingly prefer using check over tests(since ~2100 Rust packages already use that, and I'd rather not change all of them again) ...
check
tests
The new bcond syntax could probably be backported to EPEL, since it's implemented as a set of macros (just like the "old" bcond_with(out) syntax is).
bcond
bcond_with(out)
I wonder how this would interact with new koji functionality that allows RPM macros to be set on a per-tag basis. Because those macros to be set will need to be whitelisted, some standardization will be required. Might as well tackle that and --with/--without arguments at the same time.
FESCo is already discussing this, but we'd like to first approve the general idea, and then maintain a list of macros that are allowed to be overriden by this mechanism. To start with, that will probably just be %_with_bootstrap, but %_with_check would be a good second candidate (and also a good reason to standardize on this name in the packaging guidelines).
%_with_bootstrap
%_with_check
Log in to comment on this ticket.