On 3/5/19 2:03 PM, Fabiano Fidêncio wrote: > "centos7" is the preferred way to display and advertise CentOS 7, mainly > because CentOS does not support pointing releases at all. > > After talking with Jim Perrin, a CentOS board member, we've decided that > the change from centos7.0 to centos7 would be the way to go. > > As we can't break backward compatibility, we can't just rename > centos-7.0.xml.in to centos-7.xml.in and adjust the bits accordingly. > Knowing that, the path to take is creating a new centos-7.xml.in entry > that contains exactly the same content of centos-7.0.xml.in, adjust the > bits in the new entry and change centos-7.0 to "clone" centos-7. > > Although this is not the most elegant solution, it ensures we properly > advertise CentOS in the way its community wants and also do not break > backward compatibility. > > Signed-off-by: Fabiano Fidêncio <fabiano@xxxxxxxxxxxx> This strikes me as unpleasant, just to essentially fix a short-id name. Multiple <short-id> is allowed in the rng and there's some examples in data/ already, see every ubuntu entry for example. But there's no way via the API to access that info so it's presently useless. What would adding actual support for multiple <short-id> , or some kind of alias system, look like? We could add a new prop OSINFO_PRODUCT_PROP_SHORT_IDS, which instead returns a list, and get_short_ids() API to match. If apps are already using the filter APIs to do OS lookup in some way, maybe we make filtering by OSINFO_PRODUCT_PROP_SHORT_ID also check the SHORT_IDS list, so they will 'just work' in picking up the change in that respect. virt-manager doesn't use those APIs so it would need to be adjusted a bit Or stick with a single short-id and add an explicit <alias> field with OSINFO_PRODUCT_PROP_ALIASES to match, etc - Cole _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
