Klemens Böswirth

> You only need to restore errno on the exit points. I guess storing `errno` at the start of a function and restoring it at the end isn't that much...

> I would prefer to do only minimal changes (or no changes), as there were no troubles with these parts at all. The trouble IMO is that we're duplicating the...

Continued in #4521

> If we are interested in making it work like git, we need a patch to use elektraGetOpts for `kdb`. Agreed. But we should discuss the command structure of `kdb`...

> Do you propose anything different than the current command structure in the new syntax? Mostly creating `kdb plugin` and `kdb meta` commands with subcommands for the current `kdb plugin-*`...

Other problems with `kdb set` are: - `internal/**` metadata is not removed - `origvalue` metadata is not removed (breaks all future kdb get, until it is removed)

> The setup: [...] If that's the full setup, it cannot work. Neither the `type` plugin nor the any plugin for `meta:/port` are mounted. You either need an extra `spec-mount`...

Stopped before or you skipped the essential [`spec-mount` step](https://www.libelektra.org/tutorials/writing-a-specification-for-your-configuration#step-3-do-a-specification-mount). This infers the required plugins from the `meta:/` keys and creates appropriate mountpoints.

It's not about whether or not you are using a file. It's about the existence of a mountpoint. If you don't call `kdb mount` (indirectly also happens via `kdb spec-mount`),...

I agree, the sentence > This specification mount makes sure that the paths where the concrete configuration should be (app.ni) are ready to fulfill our specification (spec.ni). could be worded...