Meta: Add Flatpak linting for vcpkg version equality #6406

JanKoudijs · 2025-10-06T19:04:44Z

The Flatpak manifest linter matches dependencies against vcpkg.json and if there is a match checks if versions are equal. If there is no match it checks if there is a listed exclusion. If there is no version match or no listed exclusion then linting fails.

Merging this PR means that vcpkg.json updates have a failing CI if the Flatpak manifest isn't updated accordingly, there has to be awareness of the Flatpak existence.

gmta · 2025-10-06T19:07:53Z

You should probably swap the commits in terms of their ordering, so the linter doesn't fail for the commit you introduce it in.

JanKoudijs · 2025-10-06T19:15:11Z

I have setup the commit hooks in my local repo, including the CI linting. The first commit doesn't give issues because it does not update the Flatpak manifest or vcpkg.json, so the check is not performed.

Am I overlooking a scenario?

gmta · 2025-10-06T19:19:51Z

I have setup the commit hooks in my local repo, including the CI linting. The first commit doesn't give issues because it does not update the Flatpak manifest or vcpkg.json, so the check is not performed.

Am I overlooking a scenario?

Yes! If you look at the other tools invoked by lint-ci.sh, you'll see that their behavior is to check the paths provided to them as arguments, or they use git ls-files to enumerate all files they potentially need to check. In other words: if lint-ci.sh is run without arguments, you need to check everything there is to check in the repository.

JanKoudijs · 2025-10-07T17:44:50Z

You should probably swap the commits in terms of their ordering, so the linter doesn't fail for the commit you introduce it in.

I have swapped the commits and added the functionality to perform the test if no arguments are provided.

Meta/check-flatpak.py

gmta · 2025-10-09T08:39:24Z

Meta/check-flatpak.py

+    with open(VCPKG) as input:
+        for package in json.load(input)["overrides"]:
+            # Add name/version pair, strip any '#' postfix from the version
+            vcpkg[package["name"]] = str(package["version"]).split("#")[0]


We read all the vcpkg versions, but we don't report packages that are only mentioned in vcpkg but not the flatpak. This is a common mistake (we add a new dependency but forgot to add it to flatpak, e.g. see cpptrace). Can this script spot those as well?

The current script is indeed limited to finding mismatches in dependencies that are found in both vcpkg and the flatpak. What complicates a full version check is that Flatpak uses runtimes. The org.kde.Platform runtime we use includes commonly used libraries to reduce the size of the application Flatpak itself. Such runtime libraries are not explicitly listed in the flatpak.

I saw that today the flatpak label has been added, to trigger Flatpak builds in CI. Applying this label to PRs will also add in detecting partial version updates early.

Besides the flatpak label there is also a dependencies label, this might also be a good candidate to trigger Flatpak builds in CI.

Would these 3 together give an acceptable detection?

Btw. can this PR get the flatpak label?

we don't report packages that are only mentioned in vcpkg but not the flatpak.

The other way around also happens. Not all vcpkg dependencies have a pinned version in [overrides], preventing comparison against the flatpak. The newly added cpptrace is an example of this. I don't know if it would be good practice to pin more dependency versions in vcpkg.

The flatpak label is just for the actual build. Regular CI linting runs the script you're introducing here, that's not related to that.

cpptrace should definitely have a pinned version in vcpkg.json.

Maybe start off assuming everything must have identical versions, and keep a list of exceptions in your script?

The flatpak label is just for the actual build. Regular CI linting runs the script you're introducing here, that's not related to that.

I'm not sure I understand, does this mean that this was done after the merge and not as part of the PR checks?

We read all the vcpkg versions, but we don't report packages that are only mentioned in vcpkg but not the flatpak.

The updated script checks for dependencies that are unique for vcpkg or the flatpak if they have a listed exclusion, if not then linting fails.

Reasons for exclusion are:

Flatpak build dependencies

Flatpak dependencies of dependencies, these are not versioned in vcpkg

Flatpak runtime libraries

vcpkg dependencies specific for the non-Linux platforms

cpptrace should definitely have a pinned version in vcpkg.json.

done

The Flatpak manifest linter matches dependencies against vcpkg.json and if there is a match checks if versions are equal. If there is no match it checks if there is a listed exclusion. If there is no version match or no listed exclusion then linting fails.

gmta · 2025-10-21T22:20:14Z

Meta/check-flatpak.py

+FLATPAK_MANIFEST = "Meta/CMake/flatpak/org.ladybird.Ladybird.json"
+SELF = "Ladybird"
+
+# List of build tools that are not provided by the Flatpak SDK and therefor in the manifest


Repeated typo: "therefor" -> "therefore"

gmta · 2025-10-21T22:22:03Z

Meta/check-flatpak.py

+    "libxml2",
+    "libyuv",
+    "vulkan-memory-allocator",
+    "zstd",


Apart from vulkan-memory-allocator, seems like we pull all of these in as part of a vcpkg build. Shouldn't we pin these versions in vcpkg.json as well, even though they're transitive dependencies? 🤔

I now query the version from the vcpkg baseline if it is not found in vcpkg overrides. As the vcpkg repo isn't necessarily available at the time of linting, it is (shallow) cloned if needed. Is this an acceptable approach for a linter?

I took this approach over manual pinning of transitive dependencies as I think that will be error prone. When e.g. only a top level dependency gets updated you can end up with incompatible versions.

This added functionality revealed 3 packages in the flatpak that were older compared to the vcpkg baseline, these are now aligned.

gmta · 2025-10-21T22:23:44Z

Meta/check-flatpak.py

+    "qtbase",
+    "qtmultimedia",
+    "sqlite3",
+    "zlib",


Does this mean that we're linking against whatever the kde runtime gives us for these libraries in terms of their versions? These are all pretty critical, wouldn't it be safer to build against the exact same versions as those in vcpkg.json?

Technically this can be done, but anticipating a future Flathub submission, I'm not sure about this. In Flathub submission PRs you see the reviewers often report that some library is in the runtime and should be used from that. They seem pretty strict in their policies.

If there is no version specified in vcpkg overrides then the vcpkg baseline is queried for the version. The baseline is what ensures dependency compatibility.

JanKoudijs force-pushed the meta-check-flatpak branch from 3a0ecb2 to d5e4b88 Compare October 7, 2025 17:26

gmta reviewed Oct 9, 2025

View reviewed changes

Meta: Bring Flatpak dependency versions in line with vcpkg versions

12599c6

JanKoudijs force-pushed the meta-check-flatpak branch 2 times, most recently from abe8284 to 05da258 Compare October 11, 2025 17:41

JanKoudijs force-pushed the meta-check-flatpak branch from 05da258 to 76683d9 Compare October 12, 2025 08:16

JanKoudijs requested a review from gmta October 14, 2025 14:57

gmta reviewed Oct 21, 2025

View reviewed changes

JanKoudijs force-pushed the meta-check-flatpak branch from ae1a5c1 to 1802a7e Compare October 23, 2025 20:34

Meta: Use vcpkg baseline as fallback for Flatpak linting

19ab3be

If there is no version specified in vcpkg overrides then the vcpkg baseline is queried for the version. The baseline is what ensures dependency compatibility.

JanKoudijs force-pushed the meta-check-flatpak branch from 1802a7e to 19ab3be Compare October 24, 2025 15:08

JanKoudijs requested a review from gmta November 2, 2025 17:57

Uh oh!

Meta: Add Flatpak linting for vcpkg version equality #6406

Are you sure you want to change the base?

Meta: Add Flatpak linting for vcpkg version equality #6406

Conversation

JanKoudijs commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gmta commented Oct 6, 2025

Uh oh!

JanKoudijs commented Oct 6, 2025

Uh oh!

gmta commented Oct 6, 2025

Uh oh!

JanKoudijs commented Oct 7, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JanKoudijs Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JanKoudijs Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

JanKoudijs commented Oct 6, 2025 •

edited

Loading

JanKoudijs Oct 10, 2025 •

edited

Loading

JanKoudijs Oct 23, 2025 •

edited

Loading