Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose os candidate type #161

Closed
wants to merge 7 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 30 additions & 0 deletions PURL-TYPES.rst
Original file line number Diff line number Diff line change
Expand Up @@ -328,6 +328,35 @@ including container images built by Docker and others:
pkg:oci/static@sha256:<digest>?repository_url=gcr.io/distroless/static&tag=latest
pkg:oci/hello-wasm@sha256:<digest>?tag=v1

os
--

``os`` for Operating Systems.

- There is no standard naming convention for operating system identifiers. It's suggested to use the ``vendor:product`` from the CPE defined in ``/etc/os-release`` as the ``namespace/name`` in the PURL.
- In case no CPE is available, the ``ID`` field from ``/etc/os-release`` can be used as both the namespace and name.
- The ``version`` field should be latest version (including patch) that the operating system has been updated to. This should closely match the ``VERSION_ID`` field in the ``/etc/os-release`` data.
- Both ``name`` and ``namespace`` are not case-sensitive and must be lowercased.
- For rolling or testing distributions, the ``version`` should be set to the rolling channel identifier or branch name. Such as ``edge`` for alpine, or ``sid`` for debian. In case no such identifier is available, no version should be set.
- For MacOS, the namespace should be set to ``apple`` and the name as ``macos``. The version string should match the ``ProductVersion`` returned by the ``sw_vers`` command.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know on which OS versions are the sw_vers and winverutils available?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't find the exact details, but both appear to be old (oldest references are around 2000 for sw_ver and much older for winver), and well-supported (availability in various windows variants for eg).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing winver to ver, which is the text version, and reports the fields that are mentioned here.

Copy link
Contributor

@jlb-bb jlb-bb Oct 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the group decides to proceed with this also some updates to https://github.com/package-url/purl-spec need to be made. The description for type, namespace, name, version do not align with the proposed use. For example type's description includes the keyword required: "the package "type" or package "protocol" such as maven, npm, nuget, gem, pypi, etc. Required." But in this proposal it is suggested an operating system is a package protocol? This is inconsistent and confusing, I am not sure encoding an operating system in the purl structure will improve comprehension of this specification?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file /etc/os-release is not universally supported by Unix-flavors. Even for Linux it appears to have been introduced initially only by those distros supporting systemd. Perhaps this should be recognized in the text?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made a change for /etc/os-release alternative. I don't think the spec can be 100% exhaustive to cover all possible operating systems, the best we can do is cover the majority of cases, and offer guidance as to what goes in each field.

I'm unsure about how the description for fields can be aligned.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We believe that clarity of the specifications helps its adoption and bug-free implementation.

- For Windows, the namespace should be set to ``microsoft`` and the name as ``windows``. For special editions, the name should be hyphenated with the ``windows`` prefix, for eg: ``windows-server``, ``windows-embedded``, ``windows-mobile`` etc. Version should match the ``Version`` as returned by the ``ver`` command.
- In case ``/etc/os-release`` is not available, an equivalent file (such as ``/etc/lsb-release``, ``/etc/release``) can be used instead.
- Optional qualifiers may include:

- ``arch``: key for a package architecture
- Examples::

pkg:os/debian/debian@11.5
pkg:os/ubuntu/ubuntu@22.04.1
pkg:os/alpine/alpine@3.7
pkg:os/fedoraproject/fedora@42?arch=x86_64
pkg:os/arch/arch
pkg:os/alpine/alpine@edge
pkg:os/oracle/linux@8.4
pkg:os/redhat/enterprise_linux@7.9
pkg:os/microsoft/windows-server@10.0.19042
pkg:os/microsoft/windows@10.0.19042

pypi
----
``pypi`` for Python packages:
Expand Down Expand Up @@ -413,6 +442,7 @@ Other candidate types to define:
- ``nim`` for Nim packages:
- ``nix`` for Nixos packages:
- ``opam`` for OCaml packages:
- ``os`` for operating system:
- ``openwrt`` for OpenWRT packages:
- ``osgi`` for OSGi bundle packages:
- ``p2`` for Eclipse p2 packages:
Expand Down