Johannes Schauer Marin Rodrigues, le dim. 07 sept. 2025 01:36:04 +0200, a ecrit: > Is what you are saying that under Hurd, mmdebstrap should be doing the same > convenience calling of fakeroot-hurd as it currently does for "fakechroot > fakeroot" such that the user does not have to prefix the call with > fakeroot-hurd?
Yes. And it does not need to be running inside fakechroot to be able to call chroot. > > > > I don't really know where one would tell mmdebstrap to just use chroot. > > > > > > That's --mode=root. > > > > But we are not root here. > > > > I mean, I understand what you mean technically, but that's not what > > users will understand from the documentation. What I understand from > > "--mode=root" is that mmdebstrap should be run as root (or be given > > sudo rights), while it's not what we want to achieve. We still do need > > fakeroot in the play to be able to get files recorded as seemingly root > > and other debian users. > > That sounds more like you'd like a differently named alias for the same option > then? Possibly, but to my mind it really looks like fakeroot, since that's what we are doing. > > > Could you try this patch: https://paste.debian.net/hidden/8e5bf3c7/ > > > > > > And then run mmdebstrap with --skip=check/root,check/canmount which should > > > disable both checks that made it fail before and then hopefully you get a > > > bit > > > further. > > > > But then permissions will be all wrong, we need fakeroot for that. > > Yes, I mean, run: > > fakeroot-hurd mmdebstrap --mode=root --skip=check/root,check/canmount ... > > I agree that this is not a good UI yet I understand the part about --skip that would go away eventually. But what looks odd to me is using --mode=root: according to the manual one would have to be root or allow sudo. Here I would have much more understood writing --mode=fakeroot. > > > Except that fakeroot is not doing chroot at all. > > > > We are misunderstanding each other because we are not talking about the > > same views. > > Yes, it's possible we are having a misunderstanding. I'd like to offer having > a > video call (jitsi.debian.social) I'm afraid I really can't make it. I litteraly have almost one hundred mails waiting since my vacation start early august, and I have a lot other activies that impose difficult time scheduling. I just don't have time on my hands, I can barely keep up with answering with what I can remember off-hand. I can't do more. > > > And even fakeroot+fakechroot is not doing any actual chroot. It's just > > > intercepting and modifying syscalls. > > > > I mean from the calling perspective, not from the actual technical > > things that get achieved. > > > > I know the latter. But I don't know the mmdebstrap code at all (and have > > just no time available to study it), but I'm quite sure that the code > > path that mmdebstrap already has to call fakeroot+fakechroot would be > > essentially the same to call fakeroot-hurd+chroot. And you do not need > > any particular hurdish knowledge there: fakeroot-hurd is usable exactly like > > fakeroot-tcp/sysv, > > In that case, (as i outlined above) mmdebstrap could re-exec itself under > fakeroot-hurd as it does for fakechroot/fakeroot right now when it is run on > hurd with --mode=auto and/or a new --mode=fakeroot-hurd or just --mode=hurd. > Is > that what you mean? Yes, though I would really simply call it --mode=fakeroot, since that's really what we are doing. > > and chroot is just the normal chroot as one would use it on linux. > > And here you mean the chroot *binary* in /usr/sbin, right? Yes. Or the chroot() function: both will work fine as non-root. Samuel
