I’ve run into several peculiarities from trying to understand dom0 packages recently.
Translating from dnf to qubes-dom0-update is complicated
And checking with sys-whonix every time for things like repoquery is getting old quickly. Why can’t we just modify dnf to suit Qubes, or create a drop-in replacement/modification? And is there a way to interact with repos that doesn’t require fetching every single time?
Weird things come from weird packages (dependencies)
xfce4-settings provides the icons for the domains widget. There is a list of 63 packages, one of which provides the individual progress bars and check or x for the Qubes Update GUI. None of them are qubes-specific.
Suspicious removal of dependencies with dnf remove
If I try to remove Network-Manager (amongst other packages, like initial-setup-gui), it goes to remove a ton of deps (63 in this case), some of which look important. It is one of these packages that removed the Qubes Update GUI individual progress indicator icons. I tested this on a separate machine, and I’ve seen no immediate repercussions save the one mentioned, but my gut instinct tells me I’ll notice at the least opportune time that I removed something important. The 63 packages are listed in the attachment (which is a .txt sent as .yml because it gave me an error for .txt) rmpkg.yml (5.4 KB)
Qubes Dependencies
This may be just me, but there are packages I can’t uninstall that I have no clue why not, like bluez-libs (this is a bluetooth lib, in dom0, right?), pulseaudio* and pipewire* (I don’t need audio in dom0, but qubes-audio-daemon and qubes-audio-dom0 depend on it, and qubes-gui-dom0 depend on those. I get the audio, but why gui?), and
The problem is that there are packages that provide things that should be included elsewhere, packages that Qubes-specific packages shouldn’t depend on, and dnf/qubes-dom0-update are difficult to work with. I’m assuming there is probably a reasoning behind these choices or simply that no one has thought about it; either way, I’m not rocking the boat and just want to understand what’s happening here.
Why can’t we just modify dnf to suit Qubes, or create a drop-in replacement/modification?
Perhaps because dom0 has no network access and needs a special way to get packages.
I don’t need audio in dom0, but qubes-audio-daemon and qubes-audio-dom0 depend on it, and qubes-gui-dom0 depend on those. I get the audio, but why gui?
Dom0 is the default guivm.
The problem is that there are packages that provide things that should be included elsewhere, packages that Qubes-specific packages shouldn’t depend on, and dnf/qubes-dom0-update are difficult to work with. I’m assuming there is probably a reasoning behind these choices or simply that no one has thought about it; either way, I’m not rocking the boat and just want to understand what’s happening here.
I meant as far as dependencies: I understand that qubes-audio* depends on pulseaudio*/pipewire*, but why does qubes-gui-dom0 depend on those? I thought the introduction of sys-audio (and sys-gui, but that’s less mature IIUC) meant these things are separate. I currently am using dom0 as the GUIVM until I get sysy-gui-gpu setup, but I don’t want audio, and therefore audio packages, in dom0. But I can’t remove them without removing GUI, which IMO should be seaprate with where Qubes is heading. I think it would benefit everybody (devs, admins, and users) to have better dependency management.
As for everything else, thank you for your response. I think this topic might should be merged with the one you just mentioned. @moderators?
I thought the introduction of sys-audio (and sys-gui, but that’s less mature IIUC) meant these things are separate.
Where is that introduction? I don’t have a sys-audio on my system (installed from scratch as 4.1 then upgraded all the way to 4.2.1) and I don’t find any official doc when searching for ‘sys-audio’. sys-gui didn’t work for me either.
So, if these two have bee introduced somehow and I have missed the news, could you please link to the relevant info?
By “introduction” I didn’t mean mainstream; I meant the existence of the option for it to be user configurable, and working pretty well. My earlier post was headed more in the direction of “since these things are looking pretty stable to me, and since this is obviously the direction Qubes is going in, I think that cleaning up dom0 and making things more modular would be a good step to take.”