The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Refactor #11308

general operatingsystemrelease fact should be deprecated

Added by Stefan Schulte over 4 years ago. Updated over 3 years ago.

Status:Needs DecisionStart date:12/09/2011
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Keywords: Affected Facter version:

We've Moved!

Ticket tracking is now hosted in JIRA:


If more than one operatingsystemrelease fact suits our system facter will try them all until one fact returns a value that is not “” or nil.

There is currently one implementation of the operatingsystemrelease fact that suits all systems:

Facter.add(:operatingsystemrelease) do
  setcode do Facter[:kernelrelease].value end

So if not special operatingsystemrelease was build for a specific OS, the one above is picked.

I’d like to see this one deprecated. I don’t see the point in duplicating facts (facter output is harder to read) and it gets hard if we want to implement a proper operatingsystemrelease fact later (#11082) because we do not know if people are already using this fact instead of using the kernelrelease fact directly.

Related issues

Related to Facter - Feature #11082: operatingsystemrelease for Solaris Closed 11/29/2011


#1 Updated by Adrien Thebo over 4 years ago

  • Status changed from Unreviewed to Needs Decision

I agree. Several facts have unreasonable or useless defaults, like this, and I’m fine with removing this. However, it could definitely break a lot of things. I’ll +1 this for a 2.0 release.

#2 Updated by Ken Barber over 4 years ago

I agree – kernelrelease != operatingsystemrelease in most cases. Except for:

  • BSD (I’ve checked this for FreeBSD, NetBSD, OpenBSD and DragonflyBSD).
  • AIX – at least I think so? Need confirmation. I have read that the right way to get the release is ‘oslevel -g’ so maybe thats a better precise way of doing it.

So I think I agree for the most part, except for the exceptions which should have the fallback to kernelrelease as a confine perhaps?

#3 Updated by Andrew Elwell almost 4 years ago

-1 for me on the concept of depreciating operatingsystemrelease on Linux. It’s a very useful variable to use with configs is this rhel 5.7, 5.8, 6.2, 6.3. etc. however there should also be an ‘operatingsystemmajorrelease’ ie giving 5,6 in the examples above. We can’t do this with lsb on minimal systems due to dependency hell (printing and graphics)

However, no issue with this needing a refactor.

#4 Updated by Stefan Schulte almost 4 years ago

Andrew, the refactor does not intend to remove the fact for Linux because we know how to get the operatingsystemrelease on Linux so the fact value makes sense.

But the operatingsystemrelease fact has a fallback in case there is no special resolver for the current operatingsystem. This fallback value is to return the kernelrelease so in the end you have two facts operatingsystemrelease and kernelrelease showing the same value. If you later intend to implement a proper operatingsystemrelease fact for this platform (as #11082 tried for solaris) you may break existing manifests.

So my point was: If we don’t know how to get the operatingsystemrelease do not return a value at all. This way we can be sure that we do not break stuff if we later come up with a proper implementation.

#5 Updated by Stefan Schulte over 3 years ago

Another fact where I do not like the defaultvalue is the osfamily fact. The default value is to return the kernel fact which in my opinion makes no sense. If we want to introduce a new osfamily fact we automatically have a change in behaviour (say we want to define a new osfamily for ArchLinux the fact value will change from Linux to ArchLinux). So I am strongly for not setting a fact at all if we do not have a natural default and don’t just use the value of another facts as defaults.

Also available in: Atom PDF