coreos / rpm-ostree

⚛📦 Hybrid image/package system with atomic upgrades and package layering
https://coreos.github.io/rpm-ostree
Other
856 stars 195 forks source link

allow `json` format for `rpm-ostree db diff --changelogs` #4924

Open mcrha opened 5 months ago

mcrha commented 5 months ago

Describe the bug

This request is related to this downstream work:
https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1947

The gnome-software currently reads the --format=block changelogs and presents that to the user. Two things:

  1. problem: the format is a plain text - it would be better to be json, with well-defined and stable split parts;
  2. question: is the block format stable? That's because gnome-software expects certain format and parses it from the free text, thus when you change the format it'll break the code.

Reproduction steps

run rpm-ostree db diff --changelogs --format=json

Expected behavior

changelog exported in json format.

Actual behavior

The command currently returns error that json format is not supported for changelogs. There is a code to generate json format without changelogs already.

System details

not applicable, though using rpm-ostree-2024.4-5.fc40

Additional information

For example:

rpm-ostree db diff --changelogs --format=block 85d1dca49dbe5476ece4e119d9bb9dca5e5b068a59e26cefbc0eabde9795a159 b2e7197ab5e54dff53f1c4d939f6cb524490350eaff719d55509e7b27f8cf2db

generates here (I skipped some lines for readability):

ostree diff commit from: 85d1dca49dbe5476ece4e119d9bb9dca5e5b068a59e26cefbc0eabde9795a159
ostree diff commit to:   b2e7197ab5e54dff53f1c4d939f6cb524490350eaff719d55509e7b27f8cf2db
Upgraded:
  alsa-sof-firmware 2023.12.1-1.fc40.noarch -> 2024.03-2.fc40.noarch
    * Wed Apr 03 2024 Jaroslav Kysela - 2024.03-2
    - Update to v2024.03

    * Tue Mar 05 2024 Jaroslav Kysela - 2023.12.1-1
    - Update to v2023.12.1
    - Add AVS topology files v2024.02

   ...

Added:
  boost-regex-1.83.0-3.fc40.x86_64
  .....
  valgrind-1:3.22.0-7.fc40.x86_64

while

rpm-ostree db diff --format=json 85d1dca49dbe5476ece4e119d9bb9dca5e5b068a59e26cefbc0eabde9795a159 b2e7197ab5e54dff53f1c4d939f6cb524490350eaff719d55509e7b27f8cf2db

returns:

{
  "ostree-commit-from" : "85d1dca49dbe5476ece4e119d9bb9dca5e5b068a59e26cefbc0eabde9795a159",
  "ostree-commit-to" : "b2e7197ab5e54dff53f1c4d939f6cb524490350eaff719d55509e7b27f8cf2db",
  "pkgdiff" : [
    [
      "boost-regex",
      0,
      {
        "NewPackage" : [ "boost-regex", "1.83.0-3.fc40", "x86_64" ]
      }
    ],
    [
      "cmark-lib",
      0,
      {
        "NewPackage" : [ "cmark-lib", "0.30.3-5.fc40", "x86_64" ]
      }
    ],
   ...
    [
      "alsa-sof-firmware",
      2,
      {
        "PreviousPackage" : [ "alsa-sof-firmware", "2023.12.1-1.fc40", "noarch" ],
        "NewPackage" : [ "alsa-sof-firmware", "2024.03-2.fc40", "noarch" ]
      }
    ],
    [
      "cpp",
      2,
      {
        "PreviousPackage" : [ "cpp", "14.0.1-0.13.fc40", "x86_64" ],
        "NewPackage" : [ "cpp", "14.0.1-0.15.fc40", "x86_64" ]
      }
    ],
...

It would be nice to have the Changelogs beside the "PreviousPackage" and "NewPackage", like:

   ...
    [
      "alsa-sof-firmware",
      2,
      {
        "PreviousPackage" : [ "alsa-sof-firmware", "2023.12.1-1.fc40", "noarch" ],
        "NewPackage" : [ "alsa-sof-firmware", "2024.03-2.fc40", "noarch" ],
        "Changelogs" : [
           { "date" : 1712102400,
             "name": "Jaroslav Kysela",
             "text": "- Update to v2024.03" },
           { "date" : 1709596800,
             "name": "Jaroslav Kysela",
             "text": " - Update to v2023.12.1\n- Add AVS topology files v2024.02" },
        ]
      }
    ],
    ...

where the date is in seconds since epoch and in UTC, but it can be also as YYYY-MM-DD, as it's a date only after all.

pwithnall commented 5 months ago

@cgwalters In the meantime, can you give some indication about the stability of the block format? We could get gnome-software to parse it in the meantime, while waiting for JSON support, if it’s not likely to change as a format during that time.

(Obviously anything you say doesn’t have to be a hard API guarantee, just an indication or best-effort kind of thing.)

cgwalters commented 5 months ago

I am 99.9% sure no one is going to have any reason to touch any of the block format code in any near future and we can add a gating CI test that the format doesn't change.

pwithnall commented 5 months ago

Thanks for the reply! I don’t think there’s a need to add a CI test for it — gnome-software is only going to use this on a best-effort basis to show which packages are being updated inside a high-level ‘OS updates’ bundle. Very few users will look at the list of packages, so it doesn’t matter if it breaks at some point. Hopefully by then we can use the JSON instead.