A GUI for package management in Cooker

,

Hello everyone!
I’ve been running the build 2315 for a week by now, and I have to say that it works beautifully. Many thanks for the good job to all the OMV devs! The installer was absolutely bug-free for my UEFI system, and the flicker-free boot was also impressive (although I’m not sure why acpi_osi has to be ‘Windows 2012’ LOL).
The question, however, is in software management. We currently have DNF anf URPMI, but no decent GUI for either of that. Plasma Discover doesn’t work as expected and sometimes it doesn’t work at all. It often hangs at installing something without giving any meaningful feedback. It is very crappy and unusable, but it is certainly not the OMV fault.
Surprisingly I haven’t found DNF Dragora in OpenMandriva repos, which is strange, because Mageia’s DNF Dragora shoudln’t be too difficult to port to OpenMandriva. So I started to build the necessary packages myself. I want top point out the following:

  • OMV already has libyui, one of Dragora’s dependencies, which is good;
  • DNF Dragora has quite a few SRC.RPM packages, which takes extra time to rebuild one by one;
  • Currently OMV is not too friendly when installing build dependencies. If I enter a missing command (like ‘cmake’), ths system doesn’t tell me that there is no such command, but instead keeps silent, as if cmake was installed but didn’t produce any output. This is kind of strange. Also, I don’t see any package groups in DNF.
    So I manually looked up OMV source package names in a web browser and used ‘dnf builddep XX’ to install their build dependencies.
    Hope I can get the working Qt-based DNF Dragora interface some time soon!
1 Like

You might find willing participants and help for dnfdragora a lot faster @ #openmandriva-cooker on Freenode IRC.

https://wiki.openmandriva.org/en/4.0/Alpha/Release_Notes#New_Features_and_Major_Changes

https://forum3.openmandriva.org/t/omlx-4-0-roadmap/2273/1

I know the developers would appreciate your help in doing this.

Also one of the authors of dnfdragora and ManaTools is @ #openmandriva-cooker. @ngompa
aka: Pharaoh_Atem, King_InuYasha, and other monikers. I suspect he could be of some significant help in what you are doing.

Thanks!

You can use Plasma’s discover GUI tool for package management.
With discover you can install software from vaious repositories:

  • official OpenMandriva
  • official flathub
  • others

Meanwhile we are about to implement manatools.

2 Likes

I’m already halfway thorugh in packaging Dnfdragora using my local spec files. Right now I have rebuilt ncurses (to fix the missing etip.h header), libyui-ncurses, libyui-mga-ncurses, libyui-bindings and dnfdaemon.
However, I’m having trouble compiling libyui-qt due to missing rpc/types.h header, which seems to be part of glibc-devel.
I’m really not willing too much to compare src rpms between MGA and OMV and find out which one of many patches or build options controls the inclusion of that headers in glibc-devel. Seems like it makes more sense to adjust the libyui-qt code, but that is beyond my skills.
Maybe you can propose a better solution, please?

It’s already done, see here: Openmandriva ABF

1 Like

It’s already done, see here: https://abf.openmandriva.org/openmandriva/libyui-qt/build_lists#?page=1&per_page=25&ownership=everything

Great! Apparently the patch implied one line only!

Well, I managed to built and install everything, but when Dnfdragora runs, it complains on dnfdaemon:

dnfdaemon client error occurred:
g-io-error-quark: GDBus.Error:org.freedesktop.DBus.Python.AttributeError: Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/dbus/service.py", line 707, in _message_cb
retval = candidate_method(self, *args, **keywords)
File "/usr/lib/python3.7/site-packages/dnfdaemon/server/init.py", line 68, in newFunc
rc = func(*args, **kwargs)
File "/usr/share/dnfdaemon/dnfdaemon-system", line 175, in ExpireCache
rc = self.expire_cache()
File "/usr/lib/python3.7/site-packages/dnfdaemon/server/init.py", line 219, in expire_cache
self.base.expire_cache()
File "/usr/lib/python3.7/site-packages/dnfdaemon/server/backend.py", line 64, in expire_cache
repo._md_expire_cache()
File "/usr/lib/python3.7/site-packages/dnf/conf/config.py", line 175, in getattr
option = getattr(self._config, name)
File "/usr/lib64/python3.7/site-packages/libdnf/conf.py", line 1759, in <lambda>
getattr = lambda self, name: _swig_getattr(self, ConfigRepo, name)
File "/usr/lib64/python3.7/site-packages/libdnf/conf.py", line 80, in _swig_getattr
raise AttributeError("‘%s’ object has no attribute ‘%s’" % (class_type.name, name))
AttributeError: ‘ConfigRepo’ object has no attribute ‘_md_expire_cache’
(36)

Similar: 1628548 – dnf is locked by another application (36)
and
Fedora 29 - dnfdragora Error

Thank you. I finally got it working: updating dnfdaemon to the latest ‘git’ version (18 September) solved the problem.
The Dnfdragora is certainly ugly, but at least it works much better than Discover.

1 Like

Yes I am one of the peoples that complained about Discover in Lx 3 from time to time. I have never used dnfdragora so can’t say if it is worse, better, or indifferent. Except for testing I use the command line for package management.

So as far as I can see Discover is working just fine in Cooker/Lx 4.

Before more knowledgeable users complain about Discover it may be worth reading the part of this where they describe what Discover is and more importantly what it isn’t.

I would like to see us try dnfdragora just to see what it is like if it is a worthy replacement. Is it a better GUI for advanced users? Is it different enough from Discover to warrant inclusion in final release? No way to know without trying it. On the other hand if it does not happen at least we have a working tool for users fearful of command line. And they can install official Flathub packages! (I know nothing about Flathub yet.)

2 Likes

image

[Troll] Does it mean it’ll stay alpha software until then? (I’m out -> )

1 Like

So they are on the safe side. Users won’t expect it properly working till then :stuck_out_tongue:

1 Like

Right now the most capable, stable and powerful GUI package manager is Rpmdrake. It is old, obsolete and written in Perl, but it still works.
Apparently, going with a newer alternative will require a lot fo resources to polish and fix the thing. I see that both Discover and Dnfdragora need a lot of attention.
There’s also Apper, which was updated in 2017 and ported to Qt5 and PackageKitQt>=1.0, but I haven’t tried it yet.
Last, there used to be Rosa-software-center (2013-2015), which was an attempt to create a modern Qt5-based GUI for Rpmdrake. It looked great, but the project has since been abandoned.