JSONPath array problem: Invalid array index definition “?(@.booted == true)]”

[rugk]

Host system details
Fedora CoreOS 34.20210427.2.1
Same system as in #2829

I’m trying to get all layered packages from the current boot.

While I first tried to use jq (my tries got so far: rpm-ostree status --booted --json|jq '.deployments | .[booted=true] | .packages | .[]’) I saw you have JSONPath built-in, so I tried to use that.

My aim is to check whether one package is already installed (and if not, later install it) in some systemd service with a Condition…

Expected vs actual behavior

$ rpm-ostree status --booted --jsonpath='$.deployments[?(@.booted == true)].packages[*]'
error: While compiling jsonpath: Invalid array index definition “?(@.booted == true)].packages[*]”

Actually a MWE is:

$ rpm-ostree status --booted --jsonpath='$.deployments[?(@.booted == true)]'
error: While compiling jsonpath: Invalid array index definition “?(@.booted == true)]”

Expected:

$ rpm-ostree status --booted --jsonpath='$.deployments[?(@.booted == true)].packages[*]’
[
  "nano"
]

I tried the JSON path on https://jsonpath.curiousconcept.com/# and https://jsonpath.com/ and both implementation seem to be fine with that JSON and printed what I’ve written above.

You can copy the input JSON from #2829 again.

Would you like to work on the issue?

As it's either a deep technical problem or an oversight of me using this thing, no.

$ rpm-ostree --version
rpm-ostree:
 Version: '2021.4'
 Git: 993616745fa9839b1158f13f659c3ce2dc68de29
 Features:
  - compose
  - rust
  - fedora-integration

[lucab]

Thanks for the report. Unfortunately JSONPath capabilities are not standardized (yet) so different implementations somehow diverged in the language surface that they support over time. In this specific case, it looks like you are trying to use a language feature which is not supported by the json-glib library we use.

While the library should be augmented to handle this syntax, for this specific usecase I think it's just quicker to directly fix #2829.

[lucab]

I did some digging into json-glib bugtracker and it looks like this missing syntax (among many other things) has already been reported at https://gitlab.gnome.org/GNOME/json-glib/-/issues/44.

[rugk]

Thanks, but is there any suggestion on what a supported syntax for me here would be now? For my specific use case? 🤔
Or is it just not possible to filter it like that?

Generally, I wonder why you choose JSONPath BTW, there a many different JSONPath-like “specifications” and after all one can also always | jq and do your own thing.

[jlebon]

Thanks, but is there any suggestion on what a supported syntax for me here would be now? For my specific use case? thinking
Or is it just not possible to filter it like that?

Try something like this:

rpm-ostree status --json | jq '.deployments | map(select(.booted))[0]["requested-packages"]'

However,

My aim is to check whether one package is already installed (and if not, later install it) in some systemd service with a Condition…

If you want a package to be unconditionally installed, then you can just rpm-ostree install --allow-inactive it. It will be inactive if the package is already in the base, and otherwise layered. If you want to handle the case where the package is already present as a layer, you can use --idempotent.

[jlebon]

If you want a package to be unconditionally installed, then you can just rpm-ostree install --allow-inactive it.

This notably handles the case where the package is currently in the base but then gets removed in a later OSTree update. The package request will go from "inactive" to "active".

[rugk]

Thanks a lot! Though I’m not sure whether I understand the difference between these two parameters. Can these be used together?
Is there any documentation for thatMan page or so? – There does not seem to be one andrpm-ostree install --help` does not really explain a lot more than you said, already.

I.e. I ideally want to handle all cases, both if it is “inactive” and if it is already layered and of course if it is not yet layered.

[jlebon]

Thanks a lot! Though I’m not sure whether I understand the difference between these two parameters. Can these be used together?

Thanks, I didn't realize --idempotent wasn't in the manpage: #2840

Yes, they can be used together because they're independent. --allow-inactive is about whether to allow a package request which will initially be inactive (because it's already in the base), while --idempotent is whether to allow a package request which has already been requested (e.g. by a previous rpm-ostree install call).

I.e. I ideally want to handle all cases, both if it is “inactive” and if it is already layered and of course if it is not yet layered.

Then yes --allow-inactive --idempotent is what you want (though if this is a provisioning script, presumably nothing has been layered yet, no?).

Looking back now, I think --idempotent should've probably been the default. As for --allow-inactive, it used to not be required, but was causing confusion among users (see #1378).

[rugk]

Thanks a lot for that help!

Of course I'll leave this issue open, because the original issue of some incomplete JSONPath support of course remains…