thanks for filing this bug. I appreciate but reject your point of view. To elaborate:
Currently the cgmanager sytemd unit is installed inactive, so by default it will not interfere with systemd. The user needs to specifically enable it. When cgmanager finds that cgroups have been pre-mounted (by systemd or someone else) it does not install release agents, so it does not interfere with the previous mounter's administration of the cgroups. When systemd-shim is not installed, cgmanager does nothing that will create or destroy login sessions or scopes. That's left entirely up to systemd. The only way cgmanager will generally be used is to create sub-cgroups either of /lxc or of a user's login session. The actual configuration of cgroups done by systemd will not be interfered with (apart from impact of /lxc, which could be an interesting issue but in no way justifies a Conflicts) When systemd becomes feature-full enough to satisfy the needs of lxc, I'll definitely seek to implement a systemd backend so that cgmanager can be considered conflicting with systemd. We can also hope that cgroup namespaces will make it upstream and obviate the need for cgmanager. For now that's not an option. In the meantime, I'm going to claim that just because I run systemd on my laptop does not mean that I cede full control of cgroups to systemd. You may use them if you insist and I won't even get in the way, but you may not co-opt them entirely. What you are basically asking for is that any software which needs the features offered by cgmanager should be not installable alongside systemd. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
