Closed #829 as completed via #2996.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/829#event-12265396820
You are receiving this because you are subscribed to this thread.
Message ID:
___
Since this had somewhat become stuck - where would one start implementing
this/what potential pitfalls are there in making this happen?
I could probably re-read the thread and get enough context, but maybe something
changed in the meantime.
--
You are receiving this because you are subscribed
After much procrastination and head-scratching: sanity requires that comments
after %endif must be allowed, just like they're allowed in C pre-processor
after which the %if-%endif support in spec is largely modelled. And if we allow
them after %endif we generally need to allow them elsewhere
3. agree with @pmatilai, changelog entries can be without comments.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As far as 3 goes, does anything other than text belong there?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Never said it'd be easy to retrofit. But basically
1) Macros are handled by the macro engine, not spec. The macro body is always
literal and must remain so, so that auto_register_macro_post() macro would
essentially emit a #-comment line.
2) Comments in build-scriptlets are shell comments, not
> The constructive solution to the problem would be supporting spec #-comments
> at arbitrary positions, just like the shell does.
Supporting spec #-comments at arbitrary positions can potentially cause some
problems. That is why I looked into spec files and search for occurrences of
#. There
To be fair, the C grammar is such that the comments are completely discarded by
the lexer, if I’m not mistaken. However, I could not find any official formal
grammar for spec files, so I’m thinking that it’s just cobbled together to make
things work. The problem is exacerbated by shell commands
I'd really like to see this addressed.
I recently started getting such warnings from a package spec I maintain. It has
several levels of nested `%if`s and cases where the `%if` and corresponding
`%else`/`%endif` are separated by many lines. It's really helpful to be able to
match up the
Okay, my bad here. I was getting build errors, but seems that it’s because a
test was failing prior. The output confused me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
But that’s just Fedora documentation, not RPM documentation, so it’s really you
who sets the restrictions, because you own the parser.
And notice how I mentioned not disconnecting the comment, because, if you do
that, you introduce additional overhead when moving/removing. One has to be
more
>From Fedora documentation [1]: "_To include comments in the spec file, use a #
>character at the start of the line._"
So the text "# with foo" in line
```%else # with foo```
is not a valid comment. If you need to use a comment near %else, you can write
e.g.:
```
%if %{with foo}
...
%else
#
https://github.com/rpm-software-management/rpm/pull/625 broke a rather
reasonable use case, i.e.
```
%if %{with foo}
...
%else # with foo
```
Not even our friendly neighborhood
https://github.com/rpm-software-management/rpm/commit/44180fc7400ea8e67a13c5581459ad13f1d14103
can be used.
What
13 matches
Mail list logo
