Thanks Andreas! I think this behavior is fine. It isn't a regression in 1:6.2+dfsg-2ubuntu6.15, and this bug is targeting upgrading. If anything, it's a little bit more verbose so users know that they should start the service manually.
Guides I see online[0] tell you to start the service after install already, and I can't imagine a scenario that you have the capability to install this package and not be able to run systemctl start after it.
It is a good point though, I'd like to have the behavior of the service started on install in future releases so I'll take a look and see if there's a more elegant solution here that we can propose to Debian. My immediate thought is to add back in --no-start, and then manually run `systemctl start qemu-guest-agent` in .postinst so that way we can skip using deb-systemd-invoke which cares about the service state. That solution doesn't feel very elegant so I'd like to do a little more research.
Thanks Andreas! I think this behavior is fine. It isn't a regression in 1:6.2+dfsg- 2ubuntu6. 15, and this bug is targeting upgrading. If anything, it's a little bit more verbose so users know that they should start the service manually.
Guides I see online[0] tell you to start the service after install already, and I can't imagine a scenario that you have the capability to install this package and not be able to run systemctl start after it.
It is a good point though, I'd like to have the behavior of the service started on install in future releases so I'll take a look and see if there's a more elegant solution here that we can propose to Debian. My immediate thought is to add back in --no-start, and then manually run `systemctl start qemu-guest-agent` in .postinst so that way we can skip using deb-systemd-invoke which cares about the service state. That solution doesn't feel very elegant so I'd like to do a little more research.
[0] - https:/ /pve.proxmox. com/wiki/ Qemu-guest- agent#Linux