On Sat, Apr 04, 2020 at 11:31:04AM +0200, Aleksandra Fedorova wrote:
> Hi,
>
> On Fri, Apr 3, 2020 at 10:38 PM Zbigniew Jędrzejewski-Szmek
> <zbyszek@xxxxxxxxx> wrote:
> >
> > On Fri, Apr 03, 2020 at 02:23:12PM -0400, Stephen Gallagher wrote:
> > > Fabio Valenti made this comment in the FESCo ticket[1].
> > >
> > > "Side note: I think more people would be amenable to including
> > > "conditionals" into their packages if they weren't only shown off as
> > > `%if eln this else that`. I think there's more value in doing "feature
> > > flags" rather than conditionalize everything based on the `dist` tag,
> > > for example something like this might even be useful in fedora
> > > branches (e.g. for bootstrapping):
> > >
> > > ```spec
> > > # at the top of the .spec file, where it's easily visible
> > > %if 0%{?eln}
> > > %bcond_with docs
> > > %else
> > > %bconf_without docs
> > > %endif
> > >
> > > # ...
> > >
> > > %if %{with docs}
> > > # do something
> > > %endif
> > > ```
> > >
> > > This makes conditionals (when they are necessary) much easier to
> > > maintain (and understand), in my experience."
> >
> > This is a side topic, and I didn't want to clutter the FESCo ticket
> > with that. But here we have threads, so I hope that you'll forgive me ;)
> >
> > If find the %bcond_with/%bcond_without pattern abhorrent.
> >
> > 1. The logic is reversed: when I see "with" I think something is enabled,
> > when I see "without" I think something is disabled. But it's actually
> > the other way around here, which I find very confusing and often get
> > the condition reversed on the first try.
> >
> > 2. The value ('0%{?eln}') in this example is expressed before the name
> > ('docs'), which is like saying 'value =: name'.
> >
> > 3. It takes five (!) lines to express the something that should be one
> > line.
> >
> > So... could we please get a way to express this in rpm with a sane syntax:
> >
> > %define_cond docs 0%{?fedora} > 0
>
> I am all for clarity and cleaner syntax.
> But I don't think this particular example is a good illustration for
> it. If we have more then one switch, or more than one set of switches
> it won't work.
>
> Something like:
>
> %if 0%{?fedora} > 0
> %define_cond docs 1
> %define_cond tests 1
> %endif
>
> %if 0%{?rhel} > 0
> %define_cond docs 0
> %define_cond tests 1
> %endif
>
> is more readable than
>
> %define_cond docs 0%{?fedora} > 0
> %define_cond tests (0%{?fedora} > 0 OR 0%{?rhel} > 0)
>
> even though there are more lines in it.
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.
Zbyszek
P.S. '%bcond <name> <default>' suggested in [1] is clearly a better
name than '%define_cond'.
[1] https://github.com/rpm-software-management/rpm/issues/941
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
