In certain cases package installations will have to set up new groups, mostly for access management.
- libvirt to access /var/run/libvirt/libvirt-sock
- lxd to access /var/lib/lxd/unix.socket
- ... also sometimes accessing files, but you get the pattern
Since logins stay as-is in regard to groups, users have to re-login to pick up those permissions and be able to use the tools.
That is often mitigated by:
- package being preinstalled, so no one realizes the issue
- people deploy a system + set up a recipe automatically and only then log in
But then there are certain cases which just "feel" bad - a.k.a: "why can't it just work after being installed".
Yes a user can easily open a new terminal or kick su/newgrp/... manually !IF! they know what to do.
The next thing that comes to mind is echoing something on install, but who reads those messages - not worth the effort IMHO.
Finally none of these commonly discussed options  will be appropriate to be run from a maintainer-script IMHO.
Nor would they fixup the Graphical UI that represents a login as well.
Please get me right, I have every now and then seen issues of "this kind" and they are often not a big deal - so triage all of those ->wishlist and ignore them, not really.
But I find it annoying since we spent so much to make Ubuntu easy to consume and having such rough edges left.
I was wondering if there is a common pattern to resolve this that might just be unknown to me yet and that I could use in packaging.
OTOH I can already feel the security concerns and bad side effects of "global group membership refreshes"
And if there would be a common pattern that really works well - we should probably think of a single dh_group_refresh or something like it instead of per package fixes.
I'm afraid there is no such mechanism, but wanted at least to ask instead of giving up prematurely.
Software Engineer, Ubuntu Server