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 :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
