Snappy

Need API/cli method to know if "is_snappy"

Bug #1481086 reported by Ben Howard
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Snappy
Fix Released
High
Unassigned

Bug Description

Standard methods of determining the OS does not distinguish between regular Ubuntu and Snappy.

(amd64)ubuntu@ip-10-0-129-208:~$ snappy list
Name Date Version Developer
ubuntu-core 2015-07-29 4 ubuntu
docker 2015-08-03 1.6.1.002 canonical
generic-amd64 2015-07-29 1.4 canonical

(amd64)ubuntu@ip-10-0-129-208:~$ lsb_release -c
Codename: vivid

(amd64)ubuntu@ip-10-0-129-208:~$ python -c 'import platform; print(platform.dist())'
('Ubuntu', '15.04', 'vivid')

Ideally, we should have:
1. lsb_release should denote it is a snappy variant and disclose the channel, i.e
   $ lsb_release --all
     Distributor ID: Ubuntu
     Description: Ubuntu 15.04
     Release: 15.04
     Codename: vivid
     Variant: ubuntu-core
     Channel: stable

2. Provide Python interface to determine if something is Snappy.

See original description
Ben Howard (darkmuggle-deactivatedaccount)
description: updated
Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 1481086] Re: Need API/cli method to know if "is_snappy"

is the "variant" widely supported? If not, given the substantial
difference between snappy and non-snappy systems, we might also use the
"Distributor ID", making that "Ubuntu Core" or "Ubuntu Personal" instead
of just "Ubuntu" when it's a snappy system. both deb-based server and
desktop could call themselves Ubuntu because their semantics for package
management are identical.

Mark

Revision history for this message
Oliver Grawert (ogra) wrote :

when we discussed it yesterday on IRC the focus was more on /etc/os-release than on lsb_release. according to http://www.freedesktop.org/software/systemd/man/os-release.html the Variant field is described as:

VARIANT=

A string identifying a specific variant or edition of the operating system suitable for presentation to the user. This field may be used to inform the user that the configuration of this system is subject to a specific divergent set of rules or default configuration settings. This field is optional and may not be implemented on all systems. Examples: "VARIANT="Server Edition"", "VARIANT="Smart Refrigerator Edition"" Note: this field is for display purposes only. The VARIANT_ID field should be used for making programmatic decisions.

...the spec also defines a VARIANT_ID which could be "core" or "personal":

VARIANT_ID=

    A lower-case string (no spaces or other characters outside of 0-9, a-z, ".", "_" and "-"), identifying a specific variant or edition of the operating system. This may be interpreted by other packages in order to determine a divergent default configuration. This field is optional and may not be implemented on all systems. Examples: "VARIANT_ID=server", "VARIANT_ID=embedded"

i assume all this is inherited from lsb options, so we should be good there too.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

OK, then variant would not be strong enough to be the snappy/core
discriminator. Perhaps we should just bite the bullet and have a
different "Distributor ID", such as "Ubuntu Core".

Mark

Michael Vogt (mvo)
Changed in snappy:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Leo Arias (elopio) wrote :

+1 here. This will let us run a different setup in the tests if we are on classic.

Revision history for this message
Michael Vogt (mvo) wrote :

This is fixed on edge, we have our own /etc/os-release now.

Changed in snappy:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.