http://bugzilla.suse.com/show_bug.cgi?id=895204 --- Comment #8 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 ? -- You are receiving this mail because: You are on the CC list for the bug.