This xsd defines the values seen in the wild for the yum updateinfo.xml file It restricts the entries to things witnessed to try and keep a limited query set. This xsd was built from public versions of updateinfo.xml. In particular the Fedora and OpenSUSE files were used as a reference. They were listed as version=1 and version=1.4 so consider this a unity of them both. All updates are children of this tag, but remember all 'id' values must be unique! Each update sits within this tag level Identifier for who is issuing the update. Can be an email address, name, or something else so long as it assigns responsibility. There are a few ways of describing the status of this update. - Is it stable? - Is it in testing? - Is it a prerelease package? - Is it the final version of this, after it went through testing? Usage should be consistant, so pick a method and stick with it. What sort of update is this? Is it a recommended update? Is it an optional update? Is it a feature change? Is it an enhancement to an existing package? Is it a bugfix? Is it a security update? Is it a new package you've never had before? Please don't use all of these pick a subset and stick with them. The suggested set is as follows: enhancement, bugfix, security, and newpackage Right now only version '1' and '1.4' are in the wild. The differences between them are as yet unknown. Is there something that I must do for this fix to work beyond merely installing the package? Should I alter a configuration setting myself or what? This space is for things you must do that the package doesn't do for you when installed. What are my distribution rights for this package? Is there a restriction in how I give it out. Does someone have a copyright? The 'title' is supposed to be very short. The 'description' should leave nothing out. This is the ground between. Think of it like an abstract to a research paper. What do I need to know that you can't fit within the title. Should the system be rebooted after the update is applied? Should the login session be restarted after the update is applied? Should the updated service be restarted after the update is applied? How would a user identify this update vs other updates. This is supposed to be a simple value. For example, SL-SA:2012-01 Please give a nice SHORT human title for this update. Try and keep it under 65 chars, it is simpler to read that way due to how yum formates its output within an 80 column terminal. What distribution is this released for? You can be specific or general Scientific Linux 6.3 or Scientific Linux 6 or even Scientific Linux. But once you pick one stick with it. For security updates only. Please rate the severity of the problem. A value of '' is in the wild, but DON'T DO THAT! When was this update released? If you had to modify the update, but it is still the same source code, you can indicate that you've made a change here. This is for making corrections to description errors and such. Any sites with documentation on this update? Any documentation needs to come with some data Where can I find this documentation? What should this documentation be titled? Try to keep it under 65 char to avoid linewrap in an 80 column terminal. What kind of documentation is it? is it a commit log or branch of a source tree?* a bug in trac? * a bug in fate? (OpenSuse)* a bug in bugzilla? a cve? something that doesn't fit well into any of these?* Is there an 'ID' associated with this documentation? * These items cannot be searched for with the plugin at this time. That may change in the future. Describe the update. We can find out what the package is for elsewhere, why is this an update to that package? Just a container for collections of package lists A collection can be used to associate particular updates with a particular release of a given distribution. You can set 'name' to the name of the release You can set the attribute 'short' to a short name for the release So if you wanted you could make releases for all of Scientific Linux and make a collection for Scientific Linux 5 with a shortname of SL5 The rpm epoch is messy, it can be NULL (which is 0) or a positive number Each update must feature a package or else we are not updating a package this lists what we must have and what we can know about a package. There is a specific list of valid arches. This should work for most anything we expect to see. To get the restriction of the checksums we must first create a simple type that limits their values to what we want To require the attributes that match the checksums we must extend the values with these attributes Then we simply put it all together to make the sum