Improving snapshot comments
Opened this issue · 3 comments
Made a bash script as "proof of work" and now using with fzf preview or just itself. Main reason is to get more info about installing, upgrading, deleting packages - which are they.
Idea is simple: parse strings from /var/log/pacman.log after all transactions with packages are completed and updating comment in *-meta.json file. Should work as post installation hook i guess.
Is it possible to add this feature in main python code? I'm not so good in Python, so I made a bash example how it might look like.. :)
The second question is: is it possible make a comment for snapshots with trigger S, e.g. Hourly shapshot, Weekly shapshot, etc?
Made a bash script as "proof of work" and now using with fzf preview or just itself. Main reason is to get more info about installing, upgrading, deleting packages - which are they.
Totally open to it - I will take a look and integrate it. Thank you!
The second question is: is it possible make a comment for snapshots with trigger S, e.g. Hourly shapshot, Weekly shapshot, etc?
Yes, though this will require some more changes.
The current logic does not fix the duration of a snapshot when it is taken. Instead, it scans and ensures the required number of snaps are kept every time the schedule runs. So there is no way to tell beforehand if a snap will be kept for a month, 6 months, etc.
I can see how knowing the duration can be helpful. It will require switching to a method where the duration of a snap is fixed as a TTL (time to live) when the snap is taken based on how many snaps exist. Let me think about it.
Just took a look. The script is great! Have some questions.
Btw for me the script did not work, due to the awk line.
But I get the gist, you want something like this -
[Installed: sdl2, libsoup3, enchant] [Upgraded: fwupd, electron5] [Removed: imagemagick]
Thoughts -
-
The above is not exactly your output, but similar.
If I am not mistaken, the action might be better to be picked up per package since one operation can do multiple things. LMK if you disagree! -
This will often generate a very large comment, e.g. during
pacman -Syusince a lot of packages will be changed. I think the currentyabsnap listwill not handle it very well. -
I am thinking if I should break this off so that this part can be easily tinkered and edited. E.g. add a config parameter, that can call arbitrary binary to get the pacman summary! Or, may be for now I will put this in a separate python file so it's easy to tweak.
Finally, moving this to post-hook makes sense. But this makes re-editing the json after-the-fact unavoidable. I will need to make some changes to handle this - let me think about it!
Btw for me the script did not work, due to the awk line.
Sad to hear that.. For me its look like this:
$ ./snaplist.sh
List of snapshots: 7
2023-10-24 12:30:22 source: /, trigger: S
2023-11-06 10:09:25 source: /, trigger: S
2023-11-10 08:29:52 source: /, trigger: S
2023-11-10 10:23:33 source: /, trigger: I, comment: pacman --color=always --sync --sysupgrade
Upgrading ark 23.08.2-2 -> 23.08.3-1, baloo-widgets 23.08.2-1 -> 23.08.3-1, libkexiv2 23.08.2-1 -> 23.08.3-1, kio-extras
23.08.2-2 -> 23.08.3-1, kuserfeedback5 1.3.0-3 -> 1.3.0-4, dolphin 23.08.2-1 -> 23.08.3-1, libkdcraw 23.08.2-1 -> 23.08.3-1,
signon-kwallet-extension 23.08.2-1 -> 23.08.3-1, kaccounts-integration 23.08.2-1 -> 23.08.3-1, gwenview 23.08.2-1 ->
23.08.3-1, kate 23.08.2-1 -> 23.08.3-1, kdeconnect 23.08.2-2 -> 23.08.3-1, konsole 23.08.2-1 -> 23.08.3-1, kwalletmanager
23.08.2-1 -> 23.08.3-1, spectacle 23.08.2-1 -> 23.08.3-1, sudo 1.9.15.p1-1 -> 1.9.15.p2-1, telegram-desktop 4.11.5-1 ->
4.11.6-1, yakuake 23.08.2-1 -> 23.08.3-1
2023-11-10 12:26:18 source: /, trigger: I, comment: /usr/bin/pacman -S --asdeps wireguard-tools
Installing wireguard-tools 1.0.20210914-1, yarn 1.22.19-1, go 2:1.21.4-1
2023-11-10 16:36:56 source: /, trigger: S
2023-11-10 18:30:16 source: /, trigger: S
But I get the gist, you want something like this
Some kind of that, but with the versions. All information already is in log, we need just make squeeze of it in human readable view.
action might be better to be picked up per package since one operation can do multiple things
It will increase size of common comment of transaction. I propose take the action from line with pacman options only. Sometimes it will be different operation, like installing or uniunstaling some packages during system update, but it not so insignificant. With the info about versions it intuitive to understand what is going on.
yabsnap list
It can be done by adding a new item, e.g. commentlong and it might show with yabsnap list --long option. By default, will be short version, like: comment: pacman -S wireguard-tools [ I: 3, U: 5, D:2 packages ]
Or just cut of long comment after 60 letters :)
Finally, moving this to post-hook makes sense. But this makes re-editing the json after-the-fact unavoidable.
I'm agree with it, will require re-editing and pacman have this opportunity by design. It’s quite strange that no one has made a parser yet. I had a look on pacman-contrib package and found only paclog-pkglist that do the same as pacman -Q.