On Mon, 26 Nov 2018 at 07:04, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: [..] > > Other problem is that dnf and rpm are executing batch of packages > > scriplets not the same order with other operations. Breaking rpm > > semantics by dnf is kind of asking for troubles. > > Thanks a lot for the report. We tested this upgrade with several > different setups (both dbus-daemon and broker installed/not installed > before the upgrade, etc.), and we didn't see this behavior. We are > aware that this update needs a reboot to fully work, but we made sure > it somewhat works even if you don't reboot. For rawhide, there is > sadly no way to mark updates as "needs reboot". 1) Nothing from any implemented scriptlets printed out such message/warning that system needs to be rebooted ASAP.. 2) Even if some scriplets would be printing something like this dnf will redirect stdout messages to /dev/null. rpm does not do this and IMO good question is why dnf is doing this, So generally your 'there is sadly no way to mark updates as "needs reboot"' is not real barrier but barrier in dnf. Other thing is that many existing scriptlets which may emit some workings or even errors are usually redirected by packagers to /dev/null. For example now it is some number of packages systemd files are still pointing to /var/run instead to /run. No one is going to fix those issues because almost no one knows that it is already reported by some systemd commands. IMO general policy about scriptlets should be not redirect stdout/stderr to /dev/null because it hides potential issues in scriplts, configuration files or other resources. 3) If all dbus connections are not stateless which if it is true would not allow restart dbus service on running system IMO it is big flaw in dbus design. In case any dbus security issues this will cause that Linux will be more like old time Windows (when application level fix required OS reboot) than modern U*nix. Hopefully this is not truth and dbus restart is possible. 4) Nevertheless my system ended up with *not enabled* dbus-broker. If it was caused by upgrade over rpm it clear sign that dnf is not fully compliant with upgrade semantics implemented in rpm. This will cause more issues in the future (why dnf is not doing upgrade by use rpm libs calls? why someone started duplicating this code? It must be some reason but splitting the code is not a solution) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
