I am proposing that OMLx, by default, should ship with a BASH script in order to allow updates to be streamlined, clearer, and easier to explain & maintain.
Conundrum: Which command to use?
Currently, out of the sources I can find, there are three differing command chains that are suggested within OM’s resources:
sudo dnf clean all ; dnf clean all ; dnf repolist
sudo dnf upgrade
How to update ROCK:
sudo dnf clean all ; dnf clean all ; dnf repolist
sudo dnf distro-sync --allowerasing
Pinned on the OpenMandriva Support chat on Matrix:
OpenMandriva is unique and must be approached as such.
Use this command to update system:
sudo dnf clean all ; dnf clean all ; sudo dnf distro-sync --refresh --allowerasing 2>&1| tee dsync-log.txt
Considering I myself have trouble remembering/deliberating how to update my system every time I update, I’m curious how beneficial to be to users of all skill levels to point to one set of keywords to update Lx.
Implementation
I’m curious if this is something the community is interested in implementing. I’ve made BASH scripts before, and I myself am curious at taking a stab at this. I can’t imagine it is extremely non-trival.
Here’s my way of tackling this task, and anyone more versed in BASH/OMLx can correct me on how this could work:
The user executes the script with superuser privileges a la:
sudo dnf renovate
Get the output of /etc/os-release and grab the value of last four letters of the value of the VERSION key.
IF the output value of step 1 is “Rock”, THEN execute something like:
sudo dnf clean all ; dnf clean all ; dnf repolist; sudo dnf upgrade 2>&1| tee dsync-log.txt`
ELSE IF the output value of step 1 is “ROME”, THEN execute something like:
sudo dnf clean all ; dnf clean all ; sudo dnf distro-sync --refresh --allowerasing 2>&1| tee dsync-log.txt`
Desirable outcomes
Consistency & ease across:
ROME, Rock, Cooker, and any other potential versions of OMLx in terms on maintenance & user experience.
Documentation & user help via the wiki, forums, community support chats, et cetera.
I.e., instead of a potentially complex and strenuous way of updating the system via the CLI, it’s a simplified, universal, and easier experience for all OMLx users around.
Do I think something like that is a good idea? Yes. Personally I would make it a “how to” here in the forum. Especially since part of the “OM Ethos” is that people who use OM are willing to understand what’s under the hood.
In fact, this would be the perfect tutorial project to actually get your feet wet. You can start with a simple alias and then move on to a full script that checks ENV variables or /etc/os-release
Fwiw, here’s what I currently have set up in my .bash_aliases file on Mint (all my other machines are remarkably alias free atm) related to this
alias update='sudo apt update'
alias upgrade='sudo apt upgrade -y'
alias updateall='sudo apt update && sudo apt upgrade -y'
alias apts='apt search'
alias install='sudo apt-get install'
alias uninstall='sudo apt-get remove'
alias debinstall='sudo dpkg -i'
I know there are “fancier” ways to organize things (somewhere I have a partially written script to dynamically build my alias file from “subfiles” - based on env variables) - found the video I was using as a guide…
Doesn’t using the OML Welcome app for updates do this?
…or the “Update SYS” button in DnfDrake?
I personally like GUIs, but if there is an issue with using a GUI for updates, I’ll use the CLI.
I never even touch Discover, pretty as it may be.
The System Update entry in the menu basically covers the required update/grade command for all releases. dnf update | upgrade is not recommended not even for Rock (this is my opinion, anyway). If you think about how someone may use Rock for a year and has learned to use dnf update throughout that time, changing that behavior will require added discipline. Not doing it, will result in a broken system. It would be best to use dnf dsync from the start.
I think a lot of good information and conversation is happening here.
I am going to look into making the actual script, packaging it, and seeing if I can get something added to the repos as a lightweight CLI equivalent of the DnfDrake update tool with the logic I described in the opening post.
@rugyada in regards to distro-sync --allowerasing, would the equivalent work the same for all versions of Lx?
If so, would it be constructive for me to submit a commit to the wiki to simply revise the How to update system article in the repos with just that one set of commands for all variants? Why or why not?
Could it also just make this the renovate alias to include by default? If so, how would I submit the alias for inclusion, as a commit to the distributionrepository?
I set an alias to have dsync run sudo dnf clean all;dnf clean all;sudo dnf distro-sync --refresh -- allowerasing and it works perfectly in Rock, ROME, and Cooker.
Well personally I always run the same command regardless if cooker, rome or rock.
Of course as always I pay attention on what console returns. No issue so far and I don’t expect any in the future.
If anyone knows any reason for not doing please tell us.
I can quickly edit the wiki if no downsides are pointed out.
I prefer one simple command to do system upgrades regardless of what branch one uses. Perhaps I am mistaken but with current defaults in dnf then sudo dnf dsync --allowerasing --refresh should be enough unless one wants to create specific logs.
Past transactions can be accessed and reverted with dnf history command. There are a number of “How To” articles on this like this one and this one. Or gasp read the documentation. I believe the commands are the same or mostly the same for dnf4 and dnf5. And yes I have used this to revert dsyncs a few times.
I think this is trying to solve a non-existent problem. Those familiar with the CLI are perfectly capable of either memorizing the proper, documented command, or creating an alias/script so they don’t have to memorize it. My setup script in my dotfiles enables an update script cribbed from @WilsonPhillips for me to do this. All I have to do is type update at the CLI and it gets done. That’s my solution; others above have provided theirs. For those comfortable at the CLI, this problem is solved.
The problem that needs to be solved is an update process for Grandma. The old Mandrake/Mandriva’s claim to fame was a graphical tool for everything, including updates. An icon would appear in the tray, and you could click it and update your system. You could even set it to update automatically and then reboot at 3 AM or some other time.
OpenMandriva needs that. It should update both from OM’s repos and any Flatpaks that have been installed.
I migrated my wife’s machine to OpenMandriva a couple weeks ago. She is not technical, but she can use a graphical UI to get around. She’s on the board of a non-profit that has weekly and monthly meetings over Zoom (Flatpak). She can’t do her updates; I have to do her updates at the CLI because of the Flatpaks (DrakeTray and Dnfdrake would handle it otherwise). It would be super-useful to empower less technical users to update their systems, and it might even bring more mainstream users to the distro.
I don’t like the way this is being framed. This isn’t about overwriting anyone’s custom aliases or settings. This is about providing a sensible default as an option for OM users that is easy to remember or understand. I’m generally of the opinion that it should be simple/easy to remember as doing something as critical as updating your OS whether it’s CLI or GUI.
I am thinking about this in the context of an unfamiliar user and how that would fit into the already established workings of OMLx as a parent distro. Considering that I am a relatively new user of Lx specifically, with nearly a decade of experience regarding how other distributions work, I think this makes a good amount of sense to at least talk about it. It’s generally expected that you’re able to update your system with a [superuser command keyword] [package manager keyword] [update/upgrade keyword]. I’m not saying OM has to do that, I’m just saying that it’s a good idea and I am providing a solution that makes sense given how OMLx operates as a distribution.
I just push up 2 or 3 times in konsole and the update command somehow magically shows back up and I hit enter. It might actually be easier than using the update in the application menu.
If you are talking about a cli tool then it would basically just be an alias. There is a system update button in om-welcome to handle updates, but no way to notify you of available updates.
I think having a default alias would be a good idea for new users, especially those that come from Fedora and have the wrong dnf commands memorized. I vote for a new name though. Maybe just tie the entire update command to an alias like om-update
I think having a default alias would be a good idea for new users, especially those that come from Fedora and have the wrong dnf commands memorized. I vote suggest a new name though. Maybe just tie the entire update command to an alias like om-update.
I 100% support the idea of naming the new default update alias closer like om-update. I see your argument there about not misleading users about how dnf works. This appears closer to how OMLx works as a parent distro. Thank you!
FlatDrake, for me anyways, just goes to a blank console and then does nothing, at least that’s what it did when I tried to update the Floorp browser.
Happily, updating Flatpaks in the CLI is as easy and impossible to forget or get wrong as it gets: “flatpak update”
the alias I use, which I actually got from @WilsonPhillips , is sudo dnf clean all;dnf clean all;sudo dnf distro-sync --refresh --allowerasing;flatpak update -y
This removes old repo data, refreshes repo metadata and updates both system packages and flatpaks all in one command.
