On Fri, Mar 1, 2019 at 12:48 AM Cole Robinson <crobinso@xxxxxxxxxx> wrote:
>
> <tree> elements in the OS DB serve two broad purposes:
>
> 1) track public URLs, so apps can easily look up an install URL and
> associated metadata like relative initrd/kernel paths
> 2) track <treeinfo> matching data, so users can use guess_os_by_tree
> with their own URL, and get an OS object back
>
> Every <tree> needs an explicit @arch value associated. This makes
> thoroughly covering case #2 difficult, because it requires enumerating
> ever supported OS arch in a <tree> block. This is useful to do for
> OS that have public URLs, because we want to enumerate those anyways.
> But for distros without public URLs (RHEL), getting coverage for #2
> requires adding a bunch of <tree> stubs for each supported @arch for
> not much gain.
>
> Additionally consider Fedora, which has primary architectures
> (aarch64, armv7hl, x86_64) and secondary architectures like ppc64le.
> The latter aren't necessarily considered official releases, so it's
> debatable whether to enumerate their install URLs in the fedora OS
> entries. However it's still useful to detect the URL as 'fedora',
> so virt-install attempts with a manually passed URL get proper defaults
> etc.
>
> This series makes it easier to add a catchall <tree> entry that is
> arch independent by specifying arch="unknown", and demonstrates using
> it to get treeinfo detection coverage for rhel5.
>
> One point: I don't think this arch=unknown will cause problems for API
> users. For case #1, users won't be interacting with this <tree>
> because it doesn't have any URL listed. For case #2, the user will
> already have to call osinfo_tree_create_from_location which will
> give a tree with relevant arch/kernel/initrd data parsed out of
> the treeinfo, and they should use that OsinfoTree object and not the
> OsinfoTree returned by guess_os_by_tree
There's a small catch though. We have to adapt the
osinfo_db_guess_os_from_tree() code to deal with the arch=unknown as
what it currently does is:
```
801 if (match_regex(os_family, tree_family) &&
802 match_regex(os_variant, tree_variant) &&
803 match_regex(os_version, tree_version) &&
804 match_regex(os_arch, tree_arch)) {
805 ret = os;
806 if (matched_tree != NULL)
807 *matched_tree = os_tree;
808 break;
809 }
```
A second comment ... *upstream* does not have the URLs, indeed and
this solution fits well there.
Downstream (not only RHEL) any other distro may have entries for each
one of their trees distributed as an additional package. For instance,
let's say we internally create something like: osinfo-db-rhel which
would have to contain all the trees with URLs ... we'd have to take
into consideration the "unknown" and avoid matching it against the
"known" ones. So, more logic to be adjusted in the
osinfo_db_guess_os_from_tree().
Considering everything said about the trees ... we still do face the
very same issues with the ISOs and we need to also decide what to do
with those.
I guess the main question here is how we can have a generic info that
can match every release of an OS ... but also have specialised entries
that *should* be taken into consideration even if they match an
"unknown" entry (before matching the right one).
Let's keep the discussion (and I'll re-post the tree series for RHEL-6
and RHEL-7 based on what we decide here).
>
> Cole Robinson (2):
> schema: Allow arch=unknown
> rhel5: add tree information
>
> data/os/redhat.com/rhel-5.10.xml.in | 7 +++++++
> data/os/redhat.com/rhel-5.11.xml.in | 7 +++++++
> data/os/redhat.com/rhel-5.4.xml.in | 7 +++++++
> data/os/redhat.com/rhel-5.5.xml.in | 7 +++++++
> data/os/redhat.com/rhel-5.6.xml.in | 7 +++++++
> data/os/redhat.com/rhel-5.7.xml.in | 7 +++++++
> data/os/redhat.com/rhel-5.8.xml.in | 7 +++++++
> data/os/redhat.com/rhel-5.9.xml.in | 7 +++++++
> data/schema/osinfo.rng.in | 1 +
> 9 files changed, 57 insertions(+)
>
> --
> 2.20.1
>
> _______________________________________________
> Libosinfo mailing list
> Libosinfo@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libosinfo
_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo
