Clarify v2 stream specification #447
Conversation
|
👍 Thanks for the clarification, @sgallagher ! |
sgallagher
force-pushed
the
spec_context
branch
from
136790d
to
f4f26ec
Compare
|
Congratulations! One of the builds has completed. 🍾 You can install the built RPMs by following these steps:
Please note that the RPMs should be used only in a testing environment. |
| tracker: http://www.example.com/ | ||
|
|
||
| # profiles: |
There was a problem hiding this comment.
These are actually some existing things that I picked up on while re-reading this description...
- Should something be explicitly noted about which profile names described below have special meaning and which are just arbitrary names? (And for the special names such as
buildrootandsrpm-buildrootrefer to the component rpm flags below?) - Does
defaultstill have special meaning and get used as a default (as the description says it does)?
There was a problem hiding this comment.
I'm going to defer to @contyk here. Petr, how much of this is accurate?
There was a problem hiding this comment.
Unfortunately, "default" has no special meaning nowadays. "buildroot" and "srpm-buildroot" are the only snowflakes we have. I'm not sure what youy mean by the component rpm flags.
There was a problem hiding this comment.
@contyk He's asking if we should include a pointer to data.components.rpms.<name>.[srpm]buildroot boolean attributes. I think the answer is yes.
There was a problem hiding this comment.
Yes, that's what I meant.
yaml_specs/modulemd_stream_v2.yaml
Outdated
| ref: somecoolbranchname | ||
|
|
||
| # buildorder |
There was a problem hiding this comment.
| # buildorder | |
| # buildorder: |
| @@ -3,15 +3,18 @@ | |||
| # for a module stream. It is always a proper subset of a `document: modulemd` | |||
| # of the same `version`. | |||
| document: modulemd-packager | |||
There was a problem hiding this comment.
One more comment... Once the modulemd_stream_v2.yaml text is settled, it would be best to tediously replicate the applicable pieces here in modulemd_packager_v2.yaml as well.
There was a problem hiding this comment.
Yeah, it probably would. 😭
sgallagher
force-pushed
the
spec_context
branch
2 times, most recently
from
ee687aa
to
b3bfd15
Compare
Signed-off-by: Stephen Gallagher <[email protected]>
sgallagher
force-pushed
the
spec_context
branch
from
b3bfd15
to
3f12435
Compare
|
OK, I updated both the In the process of reworking them to make them clearer, I had to update one of the tests which also revealed a minor bug in the output. We were emitting Another round of review would be helpful, please. |
Also updates the tests to validate the specification where changed. Signed-off-by: Stephen Gallagher <[email protected]>
sgallagher
force-pushed
the
spec_context
branch
from
3f12435
to
b548b07
Compare
|
@mmathesius Changes made |
|
Merged in 80b253e |
Related to BZ 1799036
Several fields (notably those that provide
N:S:V:C:A) were marked as being "optional" when that was really only because the packager should not be setting them.Also separates the different spec sections with blank lines for readability.
Signed-off-by: Stephen Gallagher [email protected]