<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 10, 2018 at 6:59 PM Michael Biebl <<a href="mailto:biebl@debian.org">biebl@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 10.08.2018 um 15:54 schrieb Felipe Sateler:<br>
> I'm still not sure why we parse Also= for starting. Michael, do you<br>
> remember the rationale?<br>
<br>
I think this is simply a mistake and should be corrected.<br>
Parsing Also= for dh_systemd_enable was done, so the tools behave<br>
similar to how "systemctl enable foo" would behave.<br>
I can't come up (or remember) a good idea why Also= would make sense for<br>
the start case.<br></blockquote><div><br></div><div>Hi,</div><div>thanks for all your participation in the discussion already.</div><div>For now I think we have several things to do, with rather different timelines.</div><div><br></div><div>1. Ubuntu-libvirt:</div><div>For me on the Ubuntu side since a release is rather close and we care less about sysV the immediate solution is to drop the sysV scripts and remove the Also= lines in the libvirtd.service.</div><div>I tested that and right now, it seems the only combination which makes the upgrade path work properly.</div><div><br></div><div>2. Debian-Libvirt:</div><div>I have made the change available as [1] for Guido to consider, although I'd understand if in Debian where sysV is still allowed to be switched to and no Feature Freeze nearby yet, you might wait until the changes in the dh_*systemd* tools become available.</div><div><a class="gmail_plusreply" id="gmail-plusReplyChip-1" href="mailto:agx@sigxcpu.org" tabindex="-1">@Guido Günther</a> - it would be great if you'd let me know you preference/assumption for this, since IF you pick up (some of) this then I'd want to align myself.<br></div><div>If not we have to diverge for a while and get closer in both Distributions later on again.</div><div><br></div><div>3. dh_*systemd*</div><div>I assume you'll continue as usual on the already existing referenced merge request that would fix issue #1.</div><div>Probably one of you might also work on a new change to only parse the Also= for enable/disable but not start/restart actions.</div><div><br></div><div>I'm not sure about how to do that due to the ordering of the dh_ calls, but essentially if d/rules marked a service as --no-start-on-upgrade it should be considered by all calls.</div><div>So in our case, even if virtlogd services/sockets would be dragged in via Also= or any other, they should not inherit the --restart-after-upgrade from libvirt, but keep "their own" as specified.</div><div>Not sure how you'd keep the state across different calls thou, especially as the new dh_installsystemd is no more split in dh_installinit/dh_systemd_start, but I'd leave that up to you as you know the code much better.</div><div>If you spawn other bug(s) for any of that, I'd be interested to know so I can subscribe myself to them.</div><div><br></div><div>[1]: <a href="https://salsa.debian.org/libvirt-team/libvirt/merge_requests/5">https://salsa.debian.org/libvirt-team/libvirt/merge_requests/5</a><br></div></div></div>