I saw that there is a section on wiki that talks about DNF package manager, how to install it. I followed the commands and tried it, but I wanted to know if you had also tried it and if I can trust the end result of an upgrade done with dnf dup and maybe a dnf offline-upgrade download on Opensuse. How far can I go without breaking the system?
Are there any special tricks or settings that need to be done before using it?
Is it experimental or can it be used as if you were using zypper for program installation and upgrading?
But I read on reddit that after running dnf dup, if you do zypper dup there are still some packages to update. I donât understand, why doesnât it catch everything?
I disagree. When you consider that the whole application pool is pretty much the same on all systems, I donât see why you have to be so rigid just about managing packages.
Zypperâs package locking system is far and away easier to understand and use than any other Iâve been exposed to, while dnfâs is an inexplicable PITA to try to use. This is reason enough for me to avoid dnf. I sometimes wish Fedora had a zypper option - every time I update a Fedora to include a kernel, or there are any other package(s) I donât want changed, or do want to in spite of an existing lock. Dnf pretends packages locked do not exist. Zypper doesnât do that. Instead when thereâs an existing lock, it asks how to proceed if necessary. Itâs not necessary e.g. when searching, but dnf wonât return anything thatâs locked. It is necessary when thereâs a conflict. Zypper can simply ignore the lock instead of removing it if the lock includes any wildcard, a very friendly behavior. This makes it very easy to only upgrade/install various packages if and when I choose.
90% of the time when zypper asks what to do, I donât know how to proceed, so I have to ignore the block. This is not very helpful. It seems like a waste of time and an addition of anxiety and responsibility that I would like to take away. Maybe I am wrong in thinking this way but I would like a simple system to update.
Simple and rolling release seem to me to be concepts at odds with each other. Is yours complicated by multiple optional repos causing your conflict resolution questions?
I donât know your level of expertise, but when somebody says they donât know how to proceed during an upgrade, thatâs not a âzypperâ problem
Upgrading with zypper usually is as simple as âzypper ref && zypper dupâ.
Maybe you can describe a more specific problem you encountered ? Conflicting package versions, missing dependencies⌠?
erlangen:~ # journalctl -b -7 -u dup _PID=10954 --no-pager
Oct 15 17:36:48 erlangen zypper[10954]: Retrieving repository 'Application_Geo' metadata [...............done]
Oct 15 17:36:48 erlangen zypper[10954]: Building repository 'Application_Geo' cache [...done]
Oct 15 17:36:49 erlangen zypper[10954]: Retrieving repository 'Haupt-Repository (NON-OSS)' metadata [........done]
Oct 15 17:36:49 erlangen zypper[10954]: Building repository 'Haupt-Repository (NON-OSS)' cache [...done]
Oct 15 17:36:57 erlangen zypper[10954]: Retrieving repository 'Haupt-Repository (OSS)' metadata [.........................................................................done]
Oct 15 17:36:59 erlangen zypper[10954]: Building repository 'Haupt-Repository (OSS)' cache [....done]
Oct 15 17:36:59 erlangen zypper[10954]: Loading repository data...
Oct 15 17:36:59 erlangen zypper[10954]: Reading installed packages...
Oct 15 17:37:00 erlangen zypper[10954]: Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Oct 15 17:37:00 erlangen zypper[10954]: Computing distribution upgrade...
Oct 15 17:37:00 erlangen zypper[10954]: 4 Problems:
Oct 15 17:37:00 erlangen zypper[10954]: Problem: the installed python311-PyQt6-6.5.2-1.2.x86_64 requires 'libQt6Core.so.6(Qt_6.5.3_PRIVATE_API)(64bit)', but this requirement cannot be provided
Oct 15 17:37:00 erlangen zypper[10954]: Problem: the installed python310-PyQt6-6.5.2-1.2.x86_64 requires 'libQt6Network.so.6(Qt_6.5.3_PRIVATE_API)(64bit)', but this requirement cannot be provided
Oct 15 17:37:00 erlangen zypper[10954]: Problem: the installed libQt6Network6-6.5.3-2.1.x86_64 requires 'libQt6DBus6 = 6.5.3', but this requirement cannot be provided
Oct 15 17:37:00 erlangen zypper[10954]: Problem: the installed libQt6Network6-6.5.3-2.1.x86_64 requires 'qt6-network-tls = 6.5.3', but this requirement cannot be provided
Oct 15 17:37:00 erlangen zypper[10954]: Problem: the installed python311-PyQt6-6.5.2-1.2.x86_64 requires 'libQt6Core.so.6(Qt_6.5.3_PRIVATE_API)(64bit)', but this requirement cannot be provided
Oct 15 17:37:00 erlangen zypper[10954]: deleted providers: libQt6Core6-6.5.3-2.1.x86_64
Oct 15 17:37:00 erlangen zypper[10954]: Solution 1: deinstallation of python311-PyQt6-6.5.2-1.2.x86_64
Oct 15 17:37:00 erlangen zypper[10954]: Solution 2: keep obsolete libQt6Core6-6.5.3-2.1.x86_64
Oct 15 17:37:00 erlangen zypper[10954]: Solution 3: break python311-PyQt6-6.5.2-1.2.x86_64 by ignoring some of its dependencies
Oct 15 17:37:00 erlangen zypper[10954]: Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c/d/?] (c): c
erlangen:~ #
erlangen:~ # journalctl -b -7 -u dup.service -g 'Starting|following|conflicts|Consumed'
Oct 15 17:45:26 erlangen systemd[1]: Starting zypper dist-upgrade...
Oct 15 17:45:27 erlangen zypper[16137]: The following 176 packages are going to be upgraded:
Oct 15 17:45:27 erlangen zypper[16137]: The following product is going to be upgraded:
Oct 15 17:45:27 erlangen zypper[16137]: The following NEW package is going to be installed:
Oct 15 17:45:30 erlangen zypper[16137]: Checking for file conflicts: [......done]
Oct 15 17:46:01 erlangen systemd[1]: dup.service: Consumed 22.824s CPU time.
erlangen:~ #
My experience is by no means vast. So far I have been using xubuntu and predominantly that system gave me no concern If those packages are no longer needed and are even offensive, why does zypper need my confirmation to delete them? If, on the other hand, those packages are needed for me to run a program, how do I know that if I delete them that program will no longer work? Do I have to stop the update and go and research who is using those packages? On an installation of 300 packages, it takes an archivistâs work and eventually, because I am a human, I will make mistakes.
The cases you describe are exactly why package managers exist. If a certain package is needed by a program (dependecy check) than zypper simply wonât ask you to delete it. In short, zypper or apt or dnf⌠is your archivist.
Sure, they work in slightly different ways. Personally, I like it if a program asks me before it deletes some files. Gives me the feeling of being in control
Please try the commands above posted by karlmistelberger, or maybe give an example of an update youâre having problems with. Zypper should be just fine to solve whatever problem it is.
If you want to understand how and why zypper works the way it does, read the man page, or this zypper article and further links in it.
Yesterday I uninstalled packman with yast. I basically changed all the vendors to the packages in that repository by putting them on OSS and uninstalled the ones that didnât have that option. I deleted the repository. With zypper I checked to see if there were any orphans left. I am settling in and I have to say that zypper is not bad at all and maybe I made hasty judgments. I am glad to have found this forum so active and hospitable. Thank you.
I agree. I donât think it is a matter of being rigid from the system point of view. According to distrowatch, openSUSE is an independent distro. That means it doesnât derivate or directly depend on something else. OpenSUSE has its own, unique integration.
For example, even for a simple drives automount, Yast is a reference because includes the delicate fstab operations simply inside Partitioner, under the System section. Coming from Debian derivates in my past, I used to install Gnome Disks and solve this matter with ease. In openSUSE, there is no more need, and it might even conflict, logically, because the system itself suggest his own fstab path instead of the classic â/mnt/devicename/â which is ârun/media/username/devicename/â.
So, I learned how to respect this because, most importantly, it works with no hassle.
Dnf pretends packages locked do not exist. Zypper doesnât do that. Instead when thereâs an existing lock, it asks how to proceed if necessary. Itâs not necessary e.g. when searching, but dnf wonât return anything thatâs locked. It is necessary when thereâs a conflict. Zypper can simply ignore the lock instead of removing it if the lock includes any wildcard, a very friendly behavior. This makes it very easy to only upgrade/install various packages if and when I choose. 
