Basically the closest example from the C language would be `#define`. You have
to escape line breaks the same way, leading to the same readability issues if
done extensively :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
> Eliminating ambiguity (which is _always_ buggy from somebody's perspective)
> is usually worth a fair amount of disruption in the end, and messy is in the
> eye of the beholder.
>
> ```
> %define test() \
> %if 1\
> BUG\
> %endif\
> %{nil}
> ```
>
> It's not that obvious whether the %if is
Eliminating ambiguity (which is *always* buggy from somebody's perspective) is
usually worth a fair amount of disruption in the end, and messy is in the eye
of the beholder.
```
%define test() \
%if 1\
BUG\
%endif\
%{nil}
```
It's not that obvious whether the %if is meant for the spec parser
Yes, this is really ugly :)
It turns out, though, these `%define` & `%if` constructs are not that rare
after all:
https://src.fedoraproject.org/rpms/kernel/blob/master/f/kernel.spec#_2778
I wonder how much disruption it would be for such packages if we start
requiring proper escaping. Also,
Thinking some more, it might not be such a bad idea in general to require
escapes for ambiguous constructs. There's all manner of weird behavior in this
neighbourhood, for a loosely related example:
```
%global test() \
%description
%description
%test
```
This produces an empty description in
Having looked at the PR, I think the right solution to this would be requiring
%if and its relatives escaped for this kind of usage within the spec, and error
out otherwise. How easy (or not) that is to achieve, I don't know.
--
You are receiving this because you are subscribed to this thread.
So... I was about to ask how come this then works:
```
%{?__debug_package:%{__debug_install_post}}\
%{__arch_install_post}\
%{__os_install_post}\
%{nil}
```
...but the answer is that *it doesn't*. The debug foobar gets appended to
noarch package %install too, contrary to obvious intention of the
Having revisited this again, I think I have a better grasp of the whole
mechanism now. And it's way simpler than I originally thought.
First of all, there's no such thing as "support for conditionals inside macro
definitions". Macros are just that - they may contain arbitrary text to be
This issue stems from the fact that the line continuation marker `\` has
*different* semantics in the spec-level context and in a macro definition. On
the spec level, it is used to break long `%if` statements into multiple lines.
Inside macro definitions, it's the whole body that's broken down.
Ack, thanks for chasing that down.
--
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/1198#issuecomment-619789939___
Rpm-maint
5f4fdce3041b80ef26e3a87db07ecdbd2041a9b2 is the first bad commit
commit 5f4fdce3041b80ef26e3a87db07ecdbd2041a9b2
Author: Pavlina Moravcova Varekova
Date: Mon Jul 1 13:06:35 2019 +0200
Parse multiline conditional and %include parameters correctly (#775)
Trailing '\' after multiline
It also happens in 4.15, but not 4.14.
--
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/1198#issuecomment-619785696___
```
Name: hello
Version: 1
Release: 1%{?dist}
Summary: Hello
License: Public Domain
URL: https://google.com
%if 0%{?foo} >= 8
%define test() \
%if 1\
BUG\
%endif\
%{nil}
%endif
%description
%{summary}.
%prep
%autosetup -c -T
%files
```
Make sure that `foo` is not defined in your
13 matches
Mail list logo
