-
Notifications
You must be signed in to change notification settings - Fork 52
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
Empty profile is parsed as a package with an empty name #593
Comments
The cause is that libyaml returns YAML_SCALAR_EVENT for "" instead of YAML_MAPPING_END_EVENT:
That's probably in line with YAML. I think that YAML represents empty/undefined/missing mapping value node for a mapping key by an empty scalar. I will have to check YAML specification. Otherwise, it's a bug in libyaml. Then there is a special handling for this in modulemd_yaml_parse_string_set():
which is responsible for the bogus empty package name. |
Your original document is faulty.
Literally says that there is one entry under What you actually want is:
This will give you a zero-length array, which will behave as you expect. The docs may need to clarify this, but the way it's behaving is as expected. |
My original document is without the trailing hyphen:
|
That's still incorrect, because we expect a YAML_SEQUENCE_START_EVENT here and we get nothing. The libyaml is probably just trying to treat the lack of content here as a zero-length scalar, but that's pretty much just trying to avoid aborting on an invalid syntax. |
I'm not sure whether it's invalid syntax. E.g. Perl YAML::XS is fine with it and reports the missing value as undef:
|
OK, https://yaml.org/spec/1.2.2/#72-empty-nodes says that they are technically valid and are to be interpreted as a zero-length scalar, which is commonly treated as synonymous with a "null" value. It's still a violation of the libmodulemd specification which requires a sequence here, but I suppose we can be overly-cautious and catch this unusual case. If we get a zero-length scalar here, just treat it as a zero-length array of rpm names. |
Parsing a profile with an undefined rpms list: document: modulemd version: 2 data: name: test stream: A summary: Test. description: > Test. license: module: [ MIT ] profiles: profileA: rpms: lead to a nonempty list containing an empty-name package: profiles: profileA: rpms: - while user probably wanted: profiles: profileA: rpms: [] This patch changes interpretation of the top-most excerpt from the middle one to the last one. fedora-modularity#593
Parsing a profile with an undefined rpms list: document: modulemd version: 2 data: name: test stream: A summary: Test. description: > Test. license: module: [ MIT ] profiles: profileA: rpms: lead to a nonempty list containing an empty-name package: profiles: profileA: rpms: - while user probably wanted: profiles: profileA: rpms: [] This patch changes interpretation of the top-most excerpt from the middle one to the last one. fedora-modularity#593
Having this document (empty profiles are legal https://docs.fedoraproject.org/en-US/modularity/policies/packaging-guidelines/#_profiles):
reading and writing results into:
This is a bug on parser side:
Possibly all rpms lists are affected.
The text was updated successfully, but these errors were encountered: