Hi again,
Quoting Samuel Thibault (2025-09-07 01:48:11)
> 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.
okay, that should be easy to implement.
> > 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.
Okay, if you think that this would be least confusing for hurd users, then
mmdebstrap could just overload the existing --mode=fakeroot mode with different
functionality (i.e. re-exec mmdebstrap under fakeroot-hurd) if mmdebstrap is
executed on hurd.
Do you think it would make sense to add an extra alias like
--mode=fakeroot-hurd? I envision that if the user calls mmdebstrap without
--mode, then the default mode (auto) should be selecting fakeroot(-hurd) on
hurd but if the user wants to be explicit, they would run it with fakeroot-hurd
to replace auto-detection with explicit mode selection. Having fakeroot-hurd as
anothera alias for fakeroot would also slightly help with documenting. What do
you think?
> > > 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.
Okay, lets forget about --mode=root. Since fakeroot-hurd is meant to be run as
a prefix to the mmdebstrap command it is a better fix for --mode=fakeroot.
> > 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.
Please do not worry. You probably saw my mail to João Pedro Malhado in bug
#1104405 which apparently took me 4 months to reply to. I'm currently on
vacation and am sloooowly working down my email inbox. Around May/June I barely
had any time for Debian because of exam season. I do not mean to put any
pressure on you. Please do what is best for you. I hope we all do this because
we have fun with this and I do not want to make working on Debian less fun for
somebody else.
That being said, I think we got to the bottom of the misunderstanding (I hope)
and the next thing to do is for me to create a QEMU VM with hurd and try this
out myself. As I said, since the mmdebstrap testsuite runs inside qemu, I could
even add hurd tests to the mmdebstrap testsuite to avoid regressions in the
future.
As far as I'm concerned, running this on hurd should *just work* and create a
usable tarball:
mmdebstrap unstable chroot.tar
> > 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.
Okay. Lets do that!
> > > 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.
Perfect. Next on my todo list is to fix img2pdf, then mmdebstrap, then sbuild
and *then* I'll have time for this.
I'll keep you all updated.
Thanks!
cheers, joschAttachment:
signature.asc
Description: signature