[Rpm-maint] [rpm-software-management/rpm] Triple operator for conditional shortcut (#115)

pavlinamv notifications at github.com
Fri Dec 7 15:19:38 UTC 2018


Notation 

    %{?{condition}:true:false}
    %{!?{condition}:false:true}

looks promising for me.

1) It is because it causes no problems in old macros. 
2) It looks quite naturaly, the only difference from the most expected notation are curly baces around the condition. (They are added to reach 1).

Similar notations that can be chosen instead:

    %{?{condition}:true!false}
    %{?{condition}?true!false}
    %{?{condition}?true:false}
    ..

More detailed description of the notation:
- Between the first chars "%{?" resp. "%{!?" or "%{?!" there can not be a space. 
- On the other hand arround {condition} and :, there can but not need to be a space.
- In {condition}, there can be a space before or after condition.
It should be highly recommended to use %{true} and %{false} instead of true or false.

It can not cause problems in the existing macros because:
If curly brackets around condition occure in the existing spec file, the current implementation resolves
%{?{condition} .... } to "" (all cases without the space between '?' and '{' are resolved to "")
and  
%{? {condition} .... } resolves to "%".
E.g. %{!?{-n}:%{1}}%{?{-n}:%{-n*}} expands in all cases to "".
It means that the spec behaves differently than the author expected.

If the implementation will be done wisely it can change the expansion to more 
natural case:
%{!?{-n}:%{1}}%{?{-n}:%{-n*}} -> expand to %{1} or %{-n*} according to "-n".

The only different unexpected beaviour for the current spec files can arise in a case like: %{!?{condition}:sth1:sth2}. In such a case the current implementation expands it to "" and the new behaviour will expand it to sth1 or sth2. Thus it can potentially change behavior from the current one to different unexpected behavior. But such case is highly unlikely and the original behavior is already different from the expected one (as explained above). So it changes one unexpected behavior to some different one. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/115#issuecomment-445264535
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20181207/be973eca/attachment.html>


More information about the Rpm-maint mailing list