Comment # 8 on bug 895204 from Marcus Schaefer

ok, sorry for not being clear enough:

> What problems?

you suggest to search for other processes which kind of shares the mount list
and offer to kill them in a loop getting back to the user to let him decide.
This offers an unconditional optional break point in a process which should not
ask the user anything. If we don't want that we have to decide to just kill
what we think should be killed, for me a little bit too intrusive, especially
for processes kiwi hasn't spawned

> and never should be kiwi's playground

You mentioned processes like:

  rtkit-daemon, colord, and the openvpn daemon

why should kiwi cope with them ? I'm not sure if users likes us if we offer
to kill one of these. Could you estimate if the system integrity is impacted
by this ? I also think none of us currently understood why those processes
play a role at all, offering our user to kill them without being able to tell
them why is something I don't want to be responsible for :)

> Well we both know that VMs / containers are too heavyweight for local development.

I agree with regards to VMs but containers are really an option for me.
I use docker system containers to build and the overhead of starting and
stopping them via vagrant is small. Also the system resources of my laptop
and my workstation allows to run several builds in parallel. The bottleneck
is I/O but not the containers. I use a btrfs storage for docker living in a
tmpfs that's fast enough for me


> A chroot is unfortunately a poor choice for image building

I think so because it's just a move of the root mountpoint to some other path.
It's not really a contained system and it breaks kiwi's locking code
(which is bad anyway and should be improved). I don't see a real benefit for a
chroot here compared to just calling kiwi on the host. Together with osc I
understand you can benefit from osc and obs repos but from a contained build
perspective I don't see a chroot as appropriate. You share basically everything
with the host, kernel, device tree, mounts, device-mapper, processes

> What other applications do you mean, and how would they interfere? 

The stuff you already found, 

- rtkit-daemon, colord, and the openvpn daemon, for whatever reason

  and others like

- packagekitd (exclusive lock on rpm db), ok that would be solved by a chroot
- host volume group setup and therefore all LVM processes, you are basically
  forced to use different names

  ...there are more, just can't remember all the weird problems I ran into
     the last years


maybe it's just the pain from the last years but I'm a friend of locking out
the host env as much as possible instead of fiddling with it in whatever cool
and clever way

hope that makes sense ?