The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
general operatingsystemrelease fact should be deprecated
|Status:||Needs Decision||Start date:||12/09/2011|
|Keywords:||Affected Facter version:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
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 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.
#2 Updated by Ken Barber over 3 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 over 2 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 over 2 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.
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
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 2 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
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.