daemon: add option to list currently applied patches, and wanting service restart from cmdline

[nephros]

patchmanager-daemon offers the cmdline switches -a, -u, and --unapply-all to apply/unapply patches from scripts.

Feature Request 1:

-l|--list-applied

Output the list of applied patches in a parseable format, so scripts can save (and possibly restore) that information.
Useful e.g. in a system update situation, for when developing patches.

Feature Request 2:

-C|--check-services-restart

Output whether PM needs a "Services Toggle". This is useful to know before applying/unapplying patches

[nephros]

Note: both things are possible through DBus calls, but those are pain to script and parse with plain unix tools.

[Olf0]

Feature Request 2:

-C|--check-services-restart

I suggest to solely use lower case options, here -c instead of -C.
→ -c|--check-services-restart

Edit:

Feature Request 1:

-l|--list-applied

That should now be (with the new terminology): -l|--list-active

It also might make sense to add long-opts for all command line switches:

• -a|--activate
• -d|-u|--deactivate # retain "-u" for compatibility

--unapply-all was IMO deliberately only available as a long-opt, in order to prevent accidental
activation.
A nice aspect is that anyone who mistakes -u as a short-opt for --unapply-all shall receive missing argument while no action is taken.

Note: both things are possible through DBus calls, but those are pain to script and parse with plain unix tools.

What is so hard to parse, i.e., can you provide an example?
I may be able to support you a bit, but do not fully comprehend the issue yet (and generally per "grep, sed & awk" almost everything can be parsed, although they are unsuitable for really parsing XML / HTML; I think we should avoid "flex & bison", being mighty but hard to use).

[nephros]

After having dabbled in this for a bit it turns out that doing this transforms the patchmanager binary from a dbus daemon with minimal interactive interface into a dbus client-and-server hybrid.

Maybe it would be a better design to implement controlling functions into a separate patchmanager-manager tool which is just a client.

[nephros]

What is so hard to parse, i.e., can you provide an example?
I may be able to support you a bit, but do not fully comprehend the issue yet (and generally per "grep, sed & awk" almost everything can be parsed, although they are unsuitable for really parsing XML / HTML; I think we should avoid "flex & bison", being mighty but hard to use).

Thanks, but my comment there is more of a general complaint about the verbosity and amount of boilerplate that is necessary to interact with dbus.

It's all doable but rather unwieldy using classic Unix CLI. (If it takes a seven-line shell script and twelve binary calls to shove a single boolean value into a shell variable I'd rather go and do something else.)

[Olf0]

Just a high-level perspective / feedback on the D-Bus topic:

• You determine the interface the PM-daemon uses. While Andrey K. implemented this using D-Bus, I could imagine to switch to UNIX sockets or named pipes for communicating with the daemon. Though, one of the reasons why D-Bus exists is to overcome the drawbacks of classic (local) UNIX socket communication (and also to be better than named pipes).
  But if D-Bus appears / turned out to be overkill for this very purpose, why not considering using something simpler, as sockets or named pipes.
• But if you think that creating a "D-Bus frontend" is easier, that might be the way to go.
  Actually this sounds very reasonable, because it would keep the current design while making it more accessible by usual (command line) means.