Me and a couple of friends are experimenting a bit with some modifications to OM to better fit our uses. I want to streamline and par down a few things in preparation for trying XFCE with OM.
I was told never to update via Discovery store.
That leaves me with a question: Why is Discovery included in OM if it is not to be used? Why not remove it?
Not being a smart ass here, I genuinely want to know if there is a specific reason it is still here.
I don’t want to just rip it out until I know if it will break something or not. I guess I could just try it and see lol. I don’t like leaving broken things on the system unless it is a work in progress sort of situation.
Any thoughts or opinions or actual information on this?
When I look at removing discover using DNFDrake, it also wants to remove plasma6-discover-backend-flatpak. Would this remove flatpack support from FlatDrake?
Would it be better (and safer) to remove it using the CLI?
As a first step to development learning, I spent my evening reading time last night going over the package management documentation from the wiki. It does not seem any harder than the PowerShell scripts I wrote for my business automation tasks.
It is also not any more boring than my day job. I am spending today disassembling small kitchen appliances for parts to sell on eBay. I’ve got blenders, coffee machines, crock pots and food processors. Anyone need a crock pot lid?
I mean, I could not really care any less about any gui package installer, dnf is sufficient, when something is not there there is almost always a tarball or an appimage for it, currently I have almost no flatpaks (just me being lazy/not taking the time to completely remove it from my rock machine, the rome has abseloutely no flatpaks)
This has been fixed and Discover should use the correct command (dnf dsync) to upgrade Cooker and ROME systems. I test this but I do not really recommend it. Discover IMO has been a since it’s inception.
One culprit is that Discover uses packagekit it is packagekit that is the problem.
Another culprit is that the way OMLx developes and maintains software is unique and does not work well at all with packagekit
I have heard rumors that some future version of Discover will not use packagekit and will work with native package managers such as dnf or apt.
Because it is a part of KDE Plasma desktop which is the primary focus of OMLx development.
Because it is a good way for users to “Discover” software, it is a good gui tool to search for software.
What was the fix for Discover? @bero created a script that uses dnf dsync plus options to upgrade users systems instead of packagekit doing this.
Edit: My suggestion is if you don’t like it don’t use it and don’t worry about it. I don’t use it except for the occasional test.
Thanks for the good info there. I figured there was a reason. Not using it is what I’ve been doing on the machines that are in actual use. I just had the idea to experiment with removing anything that does not work 100%. Broken things nag at my OCD brain a bit. It feels like having broken glass on the floor or something. Makes me want to sweep it up into the dustpan.
It is more of a learning exercise than anything else.
I also want to eventually use XFCE as that is the best desktop IMO so I want to see how much KDE I can remove without breaking anything. KDE is rather on the heavy side for my taste and it has that weird little off-putting animation that pulses when opening a program. WTF is up with that little thing?
I also like how a PC zips like greased lightning with XFCE. Even on potato hardware. How would I make KDE work at the same speed?
My favorite machines are potatoes that I have had for many years. One has a Core Duo Quad processor with 8GB RAM and the other has an old Celeron that was never high end to begin with and 8GB RAM. I currently have Devuan on them because of XFCE performance. I have modern machines for work, but they lack the personality of these old friends.