-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add XSD schema to support info plugin's GH repo #1
base: main
Are you sure you want to change the base?
Conversation
@@ -8,6 +8,20 @@ More information as to the maintenance support period of Amazon Linux 2022 can b | |||
|
|||
The full list of core packages will be finalized during the preview. If you want to see more packages included as core packages, tell us. We will evaluate as we are collecting feedback. Feedback on Amazon Linux 2022 can be provided through your designated AWS representative or [Amazon Linux Discussion Forums](https://forums.aws.amazon.com/forum.jspa?forumID=228). | |||
|
|||
## Schema for support_info.xml file: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest we just have something shorter here, as we don't need to give the example of the makefile
+## Schema for support_info.xml file:
+
+You can validate a `support_info.xml` file against the provided XSD schema using `xmllint`:
+
+```
+xmllint --noout --schema support_info.xsd support_info.xml
+```
Invoking it as part of building the package would only be needed if doing the generation here, which would likely be a different generate.py
script rather than the main package.
|
||
<xs:complexType name="Package"> | ||
<xs:sequence> | ||
<xs:element name="max_version" type="Version" minOccurs="0" maxOccurs="1"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to have it documented if this is inclusive or not.
I would suggest we say that it is inclusive.
that is, if we have <package name="kernel"><max_version version="4.14.4000" release="5000.distag"/></package>
it would mean that the statement applies to all versions up to including kernel-4.14.4000-5000.disttag
.
</xs:complexType> | ||
|
||
<xs:complexType name="Version"> | ||
<xs:attribute name="arch" type="xs:string"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the intent here that we specify all arches that we have built, and thus the code doing the comparison needs to do this comparison?
|
||
<xs:complexType name="Version"> | ||
<xs:attribute name="arch" type="xs:string"/> | ||
<xs:attribute name="epoch" type="xs:string"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be optional, and documented as such, defaulting to zero.
<xs:attribute name="epoch" type="xs:string"/> | ||
<xs:attribute name="release" type="xs:string"/> | ||
<xs:attribute name="version" type="xs:string"/> | ||
</xs:complexType> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should very much have tests and examples here.
Adding ability to specify a version (optional field) for package in
support_info.xsd
.If specified only packages that begin with the specified version would be marked as unsupported.