In the per-XSA meta file, we used to map recipes from XenVersion to
recipe; and then the recipe itself also contained the XenVersion.
This was loaded off the disk verbatim and not checked.
This presents an opportunity to make a mistake when editing the file
by hand (or with generic JSON-parsing libraries): if they don't match,
you might ask for a recipe for 4.10 but end up with a tree based on
master.
There's no need to save the version number in each recipe in the file.
Exclude the XenVersion struct element from being marshalled, and set
it on load with the version in the map (as we set the xsa
information).
Old metadata formats will still load correctly; `xsatool NNN
canonical` will effectively remove the information.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
for i := range xm.Recipes {
xm.Recipes[i].xsa = xm.XSA
+ xm.Recipes[i].XenVersion = i
}
sort.Sort(xm.SupportedVersions)
}
type Recipe struct {
- XenVersion
Recipes map[Tree]*TreeRecipe
+ // Data not exported to JSON. Must be re-constructed on load.
+ XenVersion `json:"-"`
xsa int
}