Best way to keep pkgs in sync w/ upstream `LARBS` pkg changes?

[grant-cox]

I believe its been mentioned elsewhere, though I can't find it now, that you can keep your environment up to date with upstream LARBS pkgs by re-running the install script. Of course, this wipes your own dotfiles if you have modified voidrice. Currently I do a workaround to at least ensure system pkgs are up-to-date with upstream LARBS deployment:

#!/bin/sh

PROGS='https://raw.githubusercontent.com/LukeSmithxyz/LARBS/master/progs.csv'

curl $PROGS | grep -E '^(|A),.*' | awk -F',' '{print $2}' | xargs yay -Sy --noconfirm

This does not do everything needed if a pkg is removed upstream or replaced, nor should it, in case you still want that pkg. Recent example: pulseaudio was replaced by pipewire and friends. But the script above did warn me that pipewire was in conflict with pulseaudio and I resolved it.

Does anyone have a cleaner, or automated, way of doing this? But that would be more distro-like, which I know is not a goal of this meta-distro. :^)

A more permanent script might be one that:

1. cp existing dotfiles to a tmp dir
2. run larbs.sh
3. restore dotfiles

But that may force the end user to conform to a particular file organization method in XDG_HOME, which may also be against the philosophy of the meta distro.

[appeasementPolitik]

I'm not sure if automated is possible, but the way I do it is subscribe to the commit rss feed of all repositories (larbs, voidrice, dwm, dwmblocks and st) and manually change my system based on the changes, which works pretty well for me

[grant-cox]

@appeasementPolitik that's +/- what I do when updating my system to match the upstream changes. Hop into the git repo and look at the git logs. Thought about it over last few days and I suppose you could do it purely by viewing the git log -p progs.csv changes over time and apply them. A script could be written to iterate over each commit upstream of your current LARBS HEAD and apply the "diff" one by one.

Example: this is the patch from git log -p progs.csv where Brave was replaced with Librewolf.

commit d66112aae274318134a3f983e69bcc7675890c75
Author: Luke Smith <luke@lukesmith.xyz>
Date:   Tue Aug 2 14:09:57 2022 -0400

    switch to librewolf

diff --git a/progs.csv b/progs.csv
index 2f9ddf1..9673aef 100644
--- a/progs.csv
+++ b/progs.csv
@@ -29,7 +29,7 @@ A,gtk-theme-arc-gruvbox-git,"gives the dark GTK theme used in LARBS."
 ,man-db,"lets you read man pages of programs."
 ,ncmpcpp,"a ncurses interface for music with multiple formats and a powerful tag editor."
 ,newsboat,"is a terminal RSS client."
-A,brave-bin,"is an elegant browser with built-in adblocking, tor and other features."
+A,librewolf-bin,"the default browser of LARBS which also comes with ad-blocking and other
sensible and necessary features by default."
 A,noto-fonts,"is an expansive font package."
 ,noto-fonts-emoji,"is an emoji font."
 ,ntfs-3g,"allows accessing NTFS partitions."

a shell script could pull up this commit, pull out the packages that were added and removed, then pipe those to pacman and -S and -R appropriately. The script would do this for each commit ahead of the current state until you are "up to date".

Problems with this:

1. LARBS is installed automatically but it does not store, AFAIK, the commit hash of the version of LARBS you installed. You would have to store this in a local file or modify LARBS install to do so, then have this new updating script "start" at that commit and work forward
2. This script could be considered "bloat" since the user can read the updates and apply them themselves. But this is a plaintext and simple way to manage meta-distro changes and can be done with a shell script and no external tools.

Thoughts?

[LukeSmithxyz]

I hate to say, "You're on your own." But that's how it's always been. It ain't about hand-holding anyway. I've contemplated updating systems in the past and none of them solve more issues than they cause.

Just check for new commits and get them if you want.

LARBS used to change a lot, now it is pretty stable. The only thing I don't like is that I'd like a hardened vanilla Firefox for the default browser, but managing that can be a massive pain due to how it does profiles. Aside from that, most changes will be little tweaks that will make no differences.