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

Implement RFC 0059 - Update metadata to be consistent with RFC standard #327

Open
dmikusa opened this issue Apr 10, 2024 · 0 comments
Open
Labels
type:enhancement A general enhancement

Comments

@dmikusa
Copy link
Contributor

dmikusa commented Apr 10, 2024

Describe the Enhancement

In RFC 0059 we introduce a standard metadata format. We need to update libpak to support this format.

Possible Solution

Presently, most of the libpak metadata looks like:

  [[metadata.dependencies]]
    cpes = ["cpe:2.3:a:oracle:jdk:1.8.0:update402:*:*:*:*:*:*:*"]
    id = "jdk"
    name = "BellSoft Liberica JDK"
    purl = "pkg:generic/[email protected]?arch=amd64"
    sha256 = "e8239e9e5f046a460b3c2b92019714f9ce0da96b272c1fa78016d903cb547c94"
    source = "https://github.com/bell-sw/Liberica/releases/download/8u402+7/bellsoft-jdk8u402+7-src.tar.gz"
    source-sha256 = "da4acb30a3d613fc14766f11ba2159aaddf0428e5adda0b4bed75465f910d426"
    stacks = ["io.buildpacks.stacks.bionic", "io.paketo.stacks.tiny", "*"]
    uri = "https://github.com/bell-sw/Liberica/releases/download/8u402+7/bellsoft-jdk8u402+7-linux-amd64.tar.gz"
    version = "8.0.402"

    [[metadata.dependencies.licenses]]
      type = "GPL-2.0 WITH Classpath-exception-2.0"
      uri = "https://openjdk.java.net/legal/gplv2+ce.html"

The new format would look like:

  [[metadata.dependencies]]
    checksum = "<dependency algo:checksum>"
    id = "<dependency ID>"
    uri = "<dependency URI>"
    version = "dependency version"

    arch = "<dependency compatible architecture>" #optional
    cpes = [ "<dependency cpe>" ] #optional
    eol-date = "<dependency eol>" #optional
    name = "<dependency name>" #optional
    os = "<dependency compatible OS>" #optional
    purls = [ "<dependency purl>" ] #optional
    source = "<dependency source URI>" #optional
    source-checksum = "<dependency source algo:checksum>" #optional
    strip-components = <number of directories to strip off dependency artifact> #optional

    [[metadata.dependencies.distros]] #optional
      name = "<compatible OS distribution name>"
      version = "<compatible OS distribution version>" #optional

    [[metadata.dependencies.licenses]] #optional
      type = "<license of dependency>"
      uri = "<URI for information of license>" #optional

The new fields:

  1. checksum and source-checksum. These are new formats from an addendum to RFC 0010. We've needed to support this for a while.
  2. arch
  3. eol-date
  4. os
  5. purls, same as purl but now an array.
  6. distros name & version.
  7. strip-components. I think we only support this so that the TOML can be decoded properly. I don't think we need this as the buildpacks already have this information in the code and there doesn't seem to be a compelling reason to configure it outside of the buildpack code. If that changes, we can incorporate it into the download process at a later time.

Fields to deprecate:

  1. purl
  2. sha256
  3. source-sha256
  4. stacks

We also need to update the update tools that are in this repo.

  1. Update checksum in addition to sha256
  2. Update source-checksum in addition to source-sha256
  3. Update purls (which is now an array) in addition to purl

We still need to update the old fields as well, since we'll need to support backward compatibility until v2, when we can remove those fields.

Lastly, we need to update the download tools & cache tools. These tools primarily use the sha256 field, which should be migrated to use checksum. They also presently use purl for it's arch= parameter. We should continue to support this, but only as a fallback if arch isn't set.

Motivation

Implement RFC 0059 & 0010.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant