Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Issues with the "Kernel" and "Kernel-Version" attributes

Open
#1 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

  • #12 by @dcbaker — closed without merging

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Stale

Research direction

Start with the specification definitions for the Kernel and Kernel-Version attributes and review the concerns about uname, platform naming, and version requirements. The issue proposes removing or deprecating these attributes, but the discussion must first establish a clear requirement and decision; done means the specification reflects that agreed resolution.

Written by the indexing model from the issue text.

Description

The specification has attributes Kernel and Kernel-Version. For Kernel, the specification says

Specifies the name of the operating system kernel required by the package’s components. The value is case insensitive and should follow the output of uname -s. Typical values include "windows", "cygwin", "linux" and "darwin".

The Single UNIX Specification says that the -s flag to uname causes it to "Write the name of the implementation of the operating system.", saying nothing about the kernel.

Linux is the only OS that draws such a strong distinction between the kernel and the OS as a whole; the kernel of Darwin, for example, is called XNU, but uname -s on a Darwin-based system prints "Darwin", not "XNU".

And even the value reported by uname -s doesn't necessarily fully describe the platform on which you're running; macOS, iOS, watchOS, and tvOS all use Darwin as the "core operating system", but something that can be used on macOS might not be usable on iOS, for example.

For Linux, you'd have "GNU/Linux", i.e. Linux plus something based on GNU libc, and "Bionic/Linux", better known as "Android", and so on.

Even if Kernel were replaced by, for example, OS in the names, to indicate the full OS rather than just the OS kernel, a UN*X-only package running on multiple UN*Xes wouldn't have a single OS whose name would be "the name of the OS required by the package's components" - you might need a list such as linux,macos,ios,solaris,freebsd.

And, for OS-Version, you'd need minimum versions for multiple OSes.

My inclination would be to remove those attributes from the specification, or deprecate them, and wait until a clear need for them is established, and then, based on the requirements for such an attribute, specify attributes that address those requirements.

Dominant language
Python
Stars
191
Forks
14
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cps-org/cps

All issues in cps-org/cps

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.