Open mcrha opened 1 month ago
Yes, there is a difference. For dnf5 the symlink si created by dnf5 offline reboot
command. We can add reboot API also to dnfdaemon interface to unify the workflows.
The dnf offline reboot
is too aggressive, it really reboots the machine, which the argument claims to do, that's okay, but one cannot just prepare an update for the next reboot. When you forget to close the session with this command (which is quite likely, from my point of view), then the offline update will not happen at all and it can wait ad infinity, or until something overrides it. Hence I'd create the magic symlink also when the offline update is schedules on the command line.
There is one clash too, when you've been working on the D-Bus Offline interface it contained in some stage "the function to check whether there's a pending offline update returns true
, when there is a magic symlink". As the offline update scheduled from the command line does not create the symlink, the D-Bus API would claim "no offline update scheduled", while dnf offline status
would show a pending offline update. Meaning they two would not agree with each other. I do not know what the current state is, you might change it in some way meanwhile, I did not follow the change closely (because I do not know dnf5 code base at all).
Using dnf5-5.2.4.0-20240715005730.21.g9c2e2150.fc39.x86_64 .
When I run:
then the
dnf offline status
tells me there is prepared an offline update, but there is not created the magic symlink/system-update
.When I use the dnf5-daemon D-Bus API, the magic symlink is created.
I'd say the symlink should be created in both cases, thus the scheduled offline update is applied the next (re)boot, unless it's cancelled or anything like that.