[Libosinfo] [osinfo-db PATCH 2/7] ubuntu: Include <codename> in <name>

[Daniel P. Berrangé]

On Wed, Apr 17, 2019 at 06:38:55PM +0200, Andrea Bolognani wrote:
> 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.

<name> is opinionated in that it reflects the vendor's opinion
of what the official product name is.

In particular this does not neccessarily include the <version>
value, as with Windows, the <version> is completely distinct
from what version tag is in the product name.

Always adding the codename to <name> ourselves would be
changing what the vendor has decided their product release
is called, which I don't think is something we should do.

> 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".

That's by design, because the product name is not a simple
concatenation of a base name + version number. It is essentially
an opaque string in its own right, arbitrarily decided by the
vendor.

> 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.

The application can just display <name> field as is,
either the top level name from the OS, or the variant
name if they have identified a specific varaint.

They can optionally append a codename string to that
when displaying it.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|