Hi Christoph, I'm putting the bug back in the CC and snipped your personal note.
Quoting Christoph Groth (2022-09-03 23:06:19) > Many thanks for your very detailed answer! I learned a lot (and I still > have to digest it a bit more). > > I’m usually not debugging FTBFS but rather stuff unrelated to Debian and > some time ago I discovered that I could use mmdebstrap in the described > way. It worked for my application and I made myself some notes, but > without getting deep into it. > > Johannes Schauer Marin Rodrigues wrote: > > > it is totally possible to also use it for your use-case but that's > > rather hacky. If you want the functionality of entering a chroot you > > created and do stuff in it, maybe use some software that was meant to > > be used like that? For example you can combine mmdebstrap (for > > creating the chroot) with docker or podman or systemd-nspawn. See the > > man page for examples. > > Somehow, I mostly managed to evade containers so far. (For example the > nginx on my little cubieboard2 home server has simply been installed as > a regular Debian package.) > > If I understand correctly containers provide better encapsulation than > a chroot, and since for my debugging I don’t have any security concerns, > and since pbuilder/cowbuilder uses chroot for building and testing > packages, I thought that using a chroot is an appropriate solution for > my needs. Containers also use chroot but they use a bit more than that: linux user namespaces. Those allow separating entire process, mount and user name spaces from the rest of the system. I think most people do not use this for security purposes but because even with known software this prevents unintended modifications of the outer system. For example the default backend for sbuild is schroot which is just chroot. This means that if strange things happen, the stuff that schroot mounts into the chroot are leftover after a build and need to be manually cleaned up. Or processes can keep running and need to be cleaned up manually (if one even notices that they exist). So I added the unshare backend to sbuild which does chroot but also (like the container managers) uses linux user namespaces to encapsulate more things and thus prevent these kind of subtle bugs that need sudo to clean up. > What would I gain from using proper containers? In your case: you would gain proper file ownership which proot cannot give you. In general, I'm probably the wrong person to ask because I myself am using mmdebstrap --customize-hook='chroot "$1" bash' instead of docker, podman or systemd-nspawn. Honestly I have no clue about how to use docker properly. I can just say that those tools were made for the use-case of "enter a chroot environment" and thus (when used correctly) probably add way better usability than mmdebstrap can. It would not even be much of a security advantage because (just as the unshare mode of mmdebstrap), docker, podman and systemd-nspawn use linux user namespaces in the same way as mmdebstrap does. So if what you want to do work with proot, then I don't think there is a good reason for you to use anything else. > > So in summary, I still don't understand why proot-mode should stay. Even if > > I delete proot mode from mmdebstrap for good your use-case will still > > continue to work because you can create the chroot directory that you need > > for proot with the fakechroot mode. > > > > I would recommend you to use tarballs instead of creating directories > > for the reasons given above. But then again, since you are fine with > > proot it seems that you don't care about preserving ownership > > information. > > > > But then again, going back to your very initial issue (you want to > > debug a Debian FTBFS bug) it seems you do not need neither mmdebstrap > > nor proot and are just making your life more complicated. :) > > > > What do you think? > > I completely agree with your conclusions. Feel free to remove proot > support from mmdebstrap as far as I’m concerned. Thank you, your input was very valuable because proot was essentially broken since 16 August 2021 and I was waiting for somebody to tell me that they are a proot user and why they need it. You are a proot user but it seems that creating the chroot in fakechroot mode instead of proot still lets you do what you need. Now I guess I can remove it for good. > [snipped personal bits] Yes, I understand German but if we exchange messages in German, then most people reading this bug will not be able to understand what's going on. :) My own RCX is also still alive but my daughter is only 19 months old tomorrow, so it'll be some time before she can play with it properly. ^^ Thanks! cheers, josch
signature.asc
Description: signature
