-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement parsing of conditions #231
Labels
area/general
Related to whole service, not a specific part/integration.
complexity/single-task
Regular task, should be done within days.
gain/low
This doesn't bring that much value to users.
impact/low
This issue impacts only a few users.
kind/feature
New feature or a request for enhancement.
Comments
nforro
added
kind/bug
Something isn't working.
area/general
Related to whole service, not a specific part/integration.
complexity/single-task
Regular task, should be done within days.
gain/low
This doesn't bring that much value to users.
impact/low
This issue impacts only a few users.
workaround-exists
There is an existing workaround that can be used in the meantime of implementing the issue.
kind/feature
New feature or a request for enhancement.
and removed
kind/bug
Something isn't working.
workaround-exists
There is an existing workaround that can be used in the meantime of implementing the issue.
labels
May 22, 2023
softwarefactory-project-zuul bot
added a commit
that referenced
this issue
Aug 22, 2023
Implement processing of conditions This is not a full support for conditions, i.e. it doesn't re-solve #231 where an entire section can be conditionalized (however, the new process_conditions() function is generic enough to be used as a base for the resolution of that issue), nevertheless I think it's quite an improvement. Note that macro definitions have to be parsed twice, because a macro definition can contain a condition (see https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec for examples), and vice versa, a condition can encapsulate a macro definition. Macro definitions and tags gained a valid attribute that can be used to determine if that particular macro definition/tag is valid and can affect other entities in the spec file or if it would be ignored when parsing the spec file with RPM. This will be used to fix Specfile.update_value() and Specfile.update_tag(), but it could be beneficial for other use cases as well. Related to packit/packit#2033. RELEASE NOTES BEGIN Macro definitions and tags gained a new valid attribute. A macro definition/tag is considered valid if it doesn't appear in a false branch of any condition appearing in the spec file. RELEASE NOTES END Reviewed-by: František Lachman <[email protected]> Reviewed-by: Nikola Forró
2 tasks
Still relevant. Let us know if you need this (either in Specfile or for Packit). |
I am hitting this when parsing amavis.spec. I get this TB
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/general
Related to whole service, not a specific part/integration.
complexity/single-task
Regular task, should be done within days.
gain/low
This doesn't bring that much value to users.
impact/low
This issue impacts only a few users.
kind/feature
New feature or a request for enhancement.
Statements such as
%if
,%else
and%endif
are currently treated as regular section content.That can cause issues, especially with conditions spanning across multiple sections - if a section is deleted, modified or moved, it can lead to syntax errors as the condition block could be broken apart.
Figure out how to deal with this.
The text was updated successfully, but these errors were encountered: