@Kyle Gospo @j0rge @Marco @NerdsRun is interested in helping maintain Yafti and make improvements to it. Him and I talked quite a bit, and we are trying to determine what the scope of Yafti should be.
Based on my conversations with him, we have found a lot of the tests and code examples in the repo are surrounding flatpaks and installation of them. In Bazzite, there are a lot of ujust commands that are included as part of Yafti, which could make validating configurations done by yafti difficult unless there are stringent standards around what ujust will touch or do.
@NerdsRun is OK with including ujust or arbitrary commands as part of the scope, but it just makes it difficult due to the varying commands being handled.
so one thing that is confusing to me is why we use just to execute complex commands where we could just have yafti do it directly so just isn't so unwieldly
Here are my initial thoughts. I think anything in the scope of upstream (defined by someone ;p) should have builtin support.
Anything outside of this scope should be supported with the expectation that any additional components provide definitions for health checks / failures / idempotent installs.
I think with F40 ~2 months away we can just concentrate on fixing the user-facing issues (like the checkboxes not reflecting the state at the top level), and since the flatpaks are going into the installer then that last part with the infinite-feeling progress bar probably won't feel as long as it does now.
This is one of the oldest things in the project, I think a fresh look at use cases and what we actually need is a good idea. Bazzite didn't exist when yafti was written so it's been over a year of growth
though ... thinking aloud and future-proof ... wouldn't it be badass if one of the options was "turn on devmode" so you could DX and reboot right into it.
@Kyle Gospo do you think calling the brew ujust thing from yafti will work? I'd still like to find a way to ship it by default since we can't do it from a service unit
N
J
from me
K
N
G
F
B
E
M
