Linux Flavor Change Proposal¶
- Table of contents
- Linux Flavor Change Proposal
Historically the ups flavor has been a string with a series of components.
BASE, and kernel major/minor numbers come from
uname. In particular on Linux,
LIBC_VERSION is the version of the
glibc package; while f5, f6, ... were not yet defined; however options ups flavor -5 -6d, etc. are defined to include them should they appear.
This gives flavors like:
SunOS+5.8 IRIX+6.5 Linux+2.4-2.3 Darwin64bit+16.7.0
On Linux platforms, particularly under Docker and Singularity containers, but also in some case just for hardware support, we frequently see systems where the kernel version is not the one shipped with the release in question, but in fact something significantly different. This means that with the traditional ups flavor spelling, multiple flavor declarations (see request #17262) were needed to make software usable, or heavy use of
UPS_OVERRIDE in the environment.
glibc version turns out to be a more relevant discriminator of Linux platform/release than the kernel version.
The solution comes in two parts: (1) ignoring kernel versions, and (2) adding
First, we propose to ignore kernel versions on Linux when doing flavor comparisons. (In the current implementation, that means everything between the "
+" and the first "
-".) This addresses all of our current universe of Linux platforms: the Red Hat based distros, (Scientific Linux, CentOS, Red Hat itself) and the Debian based ones (most importantly Ubuntu).
However there remains the possibility that a pair of future releases of say, RedHat and Ubuntu (for example) sharing a
glibc version. We need a way to distinguish those platforms in the event of such a clash. Towards that end, we propose to define the 5th and 6th components of the flavor to be the abbreviation of the
lsb_release with Release major and minor versions as reported by
We further propose that part of the standard operating system installation for all Linux installations we support via UPS include
lsb_release. Note: this means that the Fermilab distributions should always include
The combination of these changes means that
ups flavor would yield:
Linux64bit+2.6-2.12-sl6-7 # Scientific Linux (Fermi or CERN) Linux64bit+2.6-2.12-c6-7 # Centos Linux64bit+2.6-2.12-rhel6-9 # Red Hat Enterprise Linux64bit+4.4-2.23-u16.0 # Ubuntu Linux64bit+3.10-2.21-lmde18.2 # Mint 18 (simulated) Darwin64bit+16.7.0 # macOS Sierra (unchanged) SunOS+5.10 # Solaris (unchanged)
The first of which will match, for example
i.e. the same platform with a different kernel. It will of course still match the subcomponents of the flavor like:
Linux64bit+2.6-2.12-sl6-9 Linux64bit+2.6-2.12-sl6 Linux64bit+2.6-2.12 Linux64bit+2.6 Linux64bit+2 Linux64bit
so existing declarations in any of these shorter forms will still work. It will also match any other kernel verison components in place of the +2.6 or +2 part of the flavor.
Note that for differentiation purposes, one need only declare products with this longer flavor (i.e -5 or -6) for the particular platform that is different; so if we had CentOS/SL/RedHat (all compatible) and Ubuntu (which isn't) all with a 2.30 libc, you could declare two instances:
and the Ubuntu systems will pick the latter, while everyone else will get the former.
Traditionally, ups flavor -2 has been sufficient to differentiate among macOS releases. This would continue unchanged.
|High Sierra||ups flavor -2||Darwin64bit+17||d17|
|Sierra||ups flavor -2||Darwin64bit+16||d16|
|El Capitan||ups flavor -2||Darwin64bit+15||d15|
|Yosemite||ups flavor -2||Darwin64bit+14||d14|
- ups v6_0_6 (released Nov. 14, 2017)
- improvement to dropit
- ups v6_0_5 (released Oct. 30, 2017)
- fully functional implementation
- more improvements to the flavor comparison
- ups v6_0_4 (released Oct. 30, 2017)
- resolve a flavor comparision issue
- ups v6_0_3 (released Oct. 19, 2017)
- respect UPS_OVERRIDE
- ups v6_0_2 (released Oct. 3, 2017)
- resolve a slow setup problem
- ups v6_0_1 (released Sep. 28, 2017)
- bug fix for a memory overrun
- ups v6_0_0 (released Sep. 26, 2017)
- initial implementation