Diagnosis scripts for eopkg (T4984)

[celticmagic]

Pierre-Yves (#kyrios123), 2017-11-08 21:24:20 UTC

It could be useful to make some diagnosis (and eventually self-repair) scripts. * Warn if running an older kernel of the used branch * If kernel headers are installed, warn about version mismatch with the loaded kernel * Warn about `-lts` packages installed on `-current` kernel and vice-versa There could be some actions around eopkg as well, it could be presented with a menu like 1. Repair broken packages 2. Rebuild the index 3. Restore default source (Shannon) And throws commands like 1. `sudo eopkg check | grep Broken | awk '{print $4}' | xargs sudo eopkg it --reinstall` 2. `sudo eopkg rdb` 3. `eopkg lr -N | head -n1 | awk '{print $1}' | xargs sudo eopkg rr` `sudo eopkg ar Solus https://packages.solus-project.com/shannon/eopkg-index.xml.xz` and so on...

[celticmagic]

Peter O'Connor (#sunnyflunk), 2017-11-09 02:39:12 UTC

I don't think a script is the ultimate goal (a very interim solution at best). Scripts make too many assumptions, and locales really mess it up. There's also the issue of having to find the script much like you have to find the commands to run that would be part of the script In order the process would be somewhat more like 1. Validate only one repo is enabled and is valid (i.e. Shannon or Unstable) and update repo 2. Validate the packages installed are actually from the latest repo index (if you install an external package it will remain provided the release # is => the repo item). Currently the only method would be matching InstalledSize. Everything blows up if the `/var` files are lost. 3. Reinstall broken packages (that command doesn't work in all languages I don't think), including those that don't match what is in the latest repo (effectively updating the system as well). It should be mandatory before any bug report and could add information that would be useful to include such as shannon or unstable/what desktop/ISO it was installed from Integration would be an important aspect. i.e. click a button to 'validate Solus' rather than running a script that won't always work. The new package manager gives a great opportunity to 1. make sure such things aren't needed and to provide something simple to validate the installation.

[celticmagic]

Pierre-Yves (#kyrios123), 2017-11-09 08:17:15 UTC

I know a script would be just like a kind of workaround and not an ultimate goal, that's why I tagged this as #low_hanging_fruit and perhaps with your experience of Solus and your deeper knowledge of the system it could be something you'd rather discourage. Actually my idea was just to have something to help users who are not comfortable with the CLI but who have to use it because something is broken. It would still be in the terminal, but at least they would have a menu and they would have to press 1, 2, 3, 4 ... instead of typing a complex command. This would also help users with a different keyboard layout who have to switch to a TTY. The locale is certainly very easy to workaround the value of `LC_ALL` could be saved in a temporary variable, so it can be changed to `en_US.utf8` before executing the command then restore its saved value. I just proposed this because many people can write shell scripts so it could be done as a collaborative work (assuming that you guys think it might be helpful and not cause more problems than it would actually help solving).

[celticmagic]

Cole (#retiform), 2018-08-26 02:13:57 UTC

A unbreak system command would be quite useful (I speak from experience of breaking Solus), though we would also probably want a method of making it obvious to users such a method exists. A recovery boot option would probably be the best way to go about it.

[TraceyC77]

Keeping in mind that we are moving to Serpent basing tooling, we have evaluate how much work this would be and how much time it would take vs. getting Serpent tooling to do this kind of thing

[TraceyC77]

We are moving to deprecating Solus Software Center in favor of Discover and GNOME Software Center. This kind of work might be feasible in eopkg, but hooking into those software centers would require upstream feature requests. Closing this since the baseline has changed so much.