On Sat, Apr 04, 2020 at 03:14:07PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
This is not what we were discussing. This should be compared with
%bcond_with/%bcond_without, which would looks like this:
%if 0%{?fedora} > 0
%bcond_without docs
%bcond_without tests
%endif
%if 0%{?rhel} > 0
%bcond_with docs
%bcond_without tests
%endif
Which IMO clearly loses the contest.
Returning to the one-definition vs. multiple-definitions issue:
I think I'd prefer the shorter version, though I admit it's pretty
close in this case.
The biggest usage problem is that rpm does not verify that everything
is assigned, so (with a longer list) it's fairly easy to forget to
define one of the items in one of the cases, silently leaving a
feature disabled.
Also, things quickly get complicated when issues depend on one another:
%define_cond docs 0%{?fedora} > 0 || 0%{rhel} >= 8
%define_cond tests 1
%define_cond doc-tests %{with_docs} && %{with_tests} && 0%{?rhel} >=
9
Ideally, we would be able to do both, and e.g. in this case use
the "verbose" style for the first two switches, and the one-line style
for the third condition.
Ideally, there should be no dist-bound conditions (%if 0%{?rhel} > 0). In the
spec file should only be a list of the switches with their default state
(on/off), possibly with a documentation:
# Build an HTML manual with ascidoc
%bcond_without docs
# Perform the tests
%bcond_without tests
The dist-bound conditional should be specified outside the spec file,
preferably on a distribution-level. E.g. RHEL decides that it does not
want to distribute a documentation, then it defines "%_without_docs 1" in srpm
build root macros.
This way the package becomes fully agnostic of the distribution it builds in.
No hard-coded exceptions anymore.
-- Petr