<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 28 April 2014 15:01, Daniel J Walsh <span dir="ltr">&lt;<a href="mailto:dwalsh@redhat.com" target="_blank">dwalsh@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The problem  is lots of services require systemd because they ship a<br>
unit file and want systemctl reload to happen.  Systemd then triggers a<br>
require for udev and kmod, which docker containers do not need.<br>
<br>
rpm -q --whatrequires systemd| wc -l<br>
151<br>
<br>
On rawhide I see 151 packages on my system which require systemd.<br>
<br>
We have a couple of options we could add a package called fakesystemd<br>
which provides a /usr/bin/systemctl that does nothing and does a<br>
provides systemd in the specfile.  Then if the user wanted to install<br>
systemd into a container it would need to obsolete the fakesystemd package.<br>
<br>
Or we could break out /usr/bin/systemctl into its own package and have<br>
it be smart enough to do nothing if systemd did not exist.<br></blockquote><div><br></div><div>Option 3 (not sure which is the best long term): Can the systemd files be broken out into seperate subpackages and that is just general practice? </div>
<div><br></div><div>Though I think a container-systemd (eg fakesystemd) might work better long term because if there turns out to be a useful talking mechanism needed between the containers and the real systemd it could be done via that packages eventual contents. </div>
</div><br clear="all"><div><br></div>-- <br><div dir="ltr">Stephen J Smoogen.<br><br></div>
</div></div>