On Wed, 2019-04-17 at 16:54 +0100, Daniel P. Berrangé wrote: > On Wed, Apr 17, 2019 at 04:45:21PM +0100, Daniel P. Berrangé wrote: > > On Wed, Apr 17, 2019 at 05:24:28PM +0200, Andrea Bolognani wrote: > > > Ubuntu releases are often referred to by their codename, so > > > it makes sense to include it when displaying information to > > > the user. > > > > IME people talking about Ubuntu rarely mention the second word > > in the codename, so I think we could just include the first > > word for brevity here. I guess that's a fair assessment. Looking at the Ubuntu mirrors you can also see that the "suite name", which appears in URLs and consequently in places like /etc/apt/sources.list, if always the shortened, lowercase version (eg. "xenial"). > > Alternatively we could just make a recommendation that apps > > displaying OS names, should append the codename in their > > display instead of forcing this on them by encoding it in > > the database ? > > I meant to also say the "Name" field was/is intended to match the > product name that the vendor primarily uses when referring to that > release. The formal name tends to just have the version number and > not the codename. > > Ubuntu is probably the exception to the rule, with them often using > the codename as shorthand, but other distros don't commonly do that. It's also very common for Debian. Taking https://www.debian.org/News/2019/20190216 as an example, the version number is mentioned three times and the codename twice; plus the same information about suites and URLs mentioned above for Ubuntu also applies. Apple seems to use the codename *only* in marketing material these days, eg. https://www.apple.com/macos/mojave/ though I'm convinced that was not the case in the past. > If we want consistency, I think we should not include the codename, > and let apps print it themselves. If we include the codename > for some OS, but not others, then it will lead to duplication if > apps append the codename themselves. I don't know... If applications want to build the display string themselves using whatever combination of <version> and <codename> they find suitable, they can still do that since we provide the various bits as separate fields, but that doesn't mean having a ready-to-go, possibly opinionated <name> field is not useful. Actually, the above is not quite correct: even if an application wanted to build the display string from scratch, they would not be able to do so because there is no field anywhere containing the strings "MacOS X", "Debian" or "Ubuntu". So perhaps we should introduce such a field, and tell applications that they now have the option to do the work themselves. Some might just not care enough to actually go through with it and will just use the display string as present in osinfo-db. There's one more detail to consider: even if the application was willing to construct the display string itself, how would it know that it's "Ubuntu Server 18.04 LTS" but "Fedora 29 Workstation"? They'd have to write code for it, and end up not handling all cases correctly... If we just provide the information is osinfo-db, on the other hand, it's just a quick API call away. [1] https://www.ubuntu.com/download/server [2] https://fedoramagazine.org/whats-new-fedora-29-workstation/ -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
