Hi! I've got once again swiped off my feet when updating to latest cooker, which I've been doing on a more sporadic basis for a while now, completely forgetting about the unsuccesful attempt at skipping restart of the display manager and it's harmful consequences yet again...
Tomasz, I know you've asked me to look into the issue a while back, and even quite some time before that, I had nearly finished implementing standard functionality in rpm for skipping any particular trigger, with type & pattern specified matching existing triggers in the distro... Unfortunately I managed to accidentally loose my work on it, and never got around to redo the implementation and finish it, but for the attempt at skipping the trigger for display manager in place, it's not really of great importance. You could still just skip the particular service the trigger would restart in the trigger as you've attempted, you just seem to have gotten some details (for which I haven't really looked into myself to determine, due to other concerns about) wrong, should be easy to fix... My concern however is more about why you've added a trigger to uncondtionally restart running services on upgrade of systemd package? I don't see much rationale for why this should be necessary, it's not like as with glibc, for which programs loads libraries from into memory, for which any changes of relevance to the running service would require it to be restarted in order to reload the updated shared libraries into memory... And for potential issues like this with glibc, we still don't even uncoditionally restart all services, but merely advice a reboot in order to do so... As the issue with the display-manager unconditionally being restarted clearly displays, doing this for services running and not unlikely even being in actual use, it certainly can pose as "quite inconvenient" in addition to the unnecessity of all cpu cycles and time spent on doing this... So as I only see problems with this behaviour, is there any rationale in place for it? Unless there is, I don't wanna even try look at and fix the issue with display manager service not being skipped, as it all seems rather potentially dangerous/problematic with this trigger existing in the first place to begin with (I'm aware of that I prolly' was the one introducing it, but that merely as part of converting systemd scriptlet macros (supposed to be?) carried with all packages having systemd services into a common trigger in one place only... Not much thought put into the why's and what not of before now taking a closer look at the problem this happens to cause, which is especially delicate (but not exclusive to) for the display manager service attempted skipped... So please enlighten me about their need & purpose, otherwise I'd advice for you to just drop it in stead. ;) -- Regards, Per Øyvind
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
