Rework just update to be a flex move

[castrojo]

I realized why I don't like the echoless just update with ublue-update. I'm either in 2 modes when I'm using my computer. Automatic, or stick shift. Sometimes I just have to do it the old fashioned way, but of course the automatic is better in every metric for everyday driving.

I propose adding topgrade-rs to the base bluefin image and then changing just update to handle that. But in a way that lets us keep ublue-update because we need that for the transparent rebase to the signed image still.

So when we want to remember what it was like to do all this stuff by hand we can use it as our nice fidget spinner. Plus it finds lots of stuff, I think it'd be an improvement and another neofetch-like thing people could show off.

[kylerankin]

I like the idea of having a tool that lets you trigger the automatic task, but in a way where you can observe (and optionally approve) each step. This is useful for debugging, and also useful whenever you want to confirm that the automated task that happens in the background is truly doing what you expected it to do.

The best automation triggers a series of well-understood, previously-manual steps, but sometimes you do want to step through that automation step-by-step and get better debugging output on what it think it did. I can foresee some day where the automatic bluefin upgrade process silently fails due to some bug, and this sort of feature might help detect/debug that faster.

[castrojo]

Alright let's see how it feels, added the binary, we'll leave the just update unchanged and see how it handles.

[ethanjli]

Looks I'm late to the discussion, but I'm excited about the proposed change! When I run just update, the sudo prompt always asks me to scan my fingerprint on my laptop's fingerprint reader - but I'm always concerned that the fingerprint scan silently failed, because echoless just update gives me no feedback about whether my fingerprint reader is still waiting for me to get a successful scan or whether the command has already started to do work. Having an alternative command which prints some output would confirm to me that my computer is indeed trying to do the update steps.

[castrojo]

The close as automatic, let's reopen to get feedback. Command is topgrade on the host.

[EyeCantCU]

After having looked over tograde, I think this is a fantastic idea. More verbosity during manual updates is a welcome change. Would also be nice to carry over to Bazzite as well

[andrewbaker-uk]

Just moved to Bluefin and I'm actually impressed by the detail topgrade gives you :)

[castrojo]

toolbx failed: 
   0: Command failed: `/usr/bin/toolbox run -c boxkit env 'TOPGRADE_PREFIX='\''Toolbx boxkit'\''' /run/host/usr/bin/topgrade --only system --no-self-update --skip-notify`
   1: `/usr/bin/toolbox` failed: exit status: 1

Location:
   src/steps/toolbx.rs:62
Retry? (y)es/(N)o/(s)hell/(q)uit

This is weird, I don't use toolboxes so maybe it's conflicting with my distroboxes?

[FlyinPancake]

The problem stems from toolbx recognizing distrobox containers as toolbx containers

You can check this out with running toolbox list it will show your distroboxes.

[m2Giles]

I need to check how distrobox tags it's own containers to see if we can add to topgrade a check that compares if it's toolbx or actually a distrobox. This might be a welcome patch since I don't think it's unheard or to have both toolbox and distrobox installed.

I also currently have some reservations about the upgrade being applied live and wonder if we can set a flag or option.

[castrojo]

Yeah apply live is an odd thing to have by default, maybe we can change their mind?

[m2Giles]

I'm not seeing where apply-live is being set in topgrade. Here's the function for FedoraImmutable.

https://github.com/topgrade-rs/topgrade/blob/78dc567226be38491dad23c4de42ed841bc46bef/src/steps/os/linux.rs#L237. I'll keep poking around the repo to see if we are pulling something else.

For getting around the toolbox trying and failing to upgrade distrobox containers, there is already a builtin flag for disable individual components. Additionally, there is a flag to ask for user input if a component fails.

But our command could look like: topgrade --disable toolbx --no-retry

And if you are using toolbox instead this could have some sort of toggle. It also has a config file as well that we can specify.

[KyleGospo]

@gerblesh I think this would be a great way to modernize ublue-update. Basically turn it into a scheduler for topgrade and reduce the maintenance burden.

@m2Giles My suggestion is we treat this like just and always call topgrade like:
topgrade --config /usr/share/ublue-os/topgrade/topgrade.toml
That config can specify other locations it looks for the end user, such as /etc/topgrade.toml

Here's a working example config:

[include]
paths = ["/etc/topgrade.toml"]

[misc]
disable = ["toolbx", "self_update"]
ignore_failures = ["distrobox, "pip3"]

[gerblesh]

@KyleGospo I 100% agree, it would also make ublue-update much easier to maintain, a couple things I'm not too sure work with topgrade is:

1. dbus notifications (and a toggle to turn them off)
2. system checks (battery, wifi/internet, RAM usage, CPU, possibly GPU)
3. multi-user updates (running user updates for active users as well as root)

I think this is definitely the way to go though, and i'm sure most of these could probably be solved by making scripts to be executed by topgrade, and (if needed) having a script to do system checks before running topgrade

[KyleGospo]

#3 should be working today, though how topgrade is launched likely matters.