Add interim summary

Christian Ehrhardt christian.ehrhardt at canonical.com
Mon Aug 13 10:39:23 BST 2018


On Fri, Aug 10, 2018 at 6:59 PM Michael Biebl <biebl at debian.org> wrote:

> Am 10.08.2018 um 15:54 schrieb Felipe Sateler:
> > I'm still not sure why we parse Also= for starting. Michael, do you
> > remember the rationale?
>
> I think this is simply a mistake and should be corrected.
> Parsing Also= for dh_systemd_enable was done, so the tools behave
> similar to how "systemctl enable foo" would behave.
> I can't come up (or remember) a good idea why Also= would make sense for
> the start case.
>

Hi,
thanks for all your participation in the discussion already.
For now I think we have several things to do, with rather different
timelines.

1. Ubuntu-libvirt:
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.
I tested that and right now, it seems the only combination which makes the
upgrade path work properly.

2. Debian-Libvirt:
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.
@Guido G√ľnther <agx at sigxcpu.org> - 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.
If not we have to diverge for a while and get closer in both Distributions
later on again.

3. dh_*systemd*
I assume you'll continue as usual on the already existing referenced merge
request that would fix issue #1.
Probably one of you might also work on a new change to only parse the Also=
for enable/disable but not start/restart actions.

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.
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.
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.
If you spawn other bug(s) for any of that, I'd be interested to know so I
can subscribe myself to them.

[1]: https://salsa.debian.org/libvirt-team/libvirt/merge_requests/5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180813/a21c7ec9/attachment-0002.html>


More information about the Pkg-systemd-maintainers mailing list