dex4er
Optional symlink extension behavior?
For the symlink syscall, I have a scenario in which I don't want fakechroot to extend the path being symlinked to (absolute or relative), and just want it to create the symlink as requested by the program being run under fakeroot. Would it be possible to make the current prefix behavior optional, or is there a better way to do what I want?
The scenario is for rootless building of disk images and certain tools need to run in a chroot and create an (absolute) symlink. So I run the tools under fakechroot and they work fine, except that the symlinks they create in the target filesystem now have my fake root path prepended to them, so I need to go fix them up before I can make my disk image.
Does that make sense?
I'd be tempted to make this a command-line option or possibly an environment variable so people can ask for either behavior.
@dex4er any thoughts?
Testing against a "real" chroot, it also doesn't replicate that behavior: if I symlink a file under a traditional chroot, it just preserves the exact path I ask for under the chroot. It seems best to default to the traditional chroot behavior and possibly make an option for the current thing. I think hard links behave properly today, since that's actually linking to a specific file and not a string that can be interpreted as a path.
I'm seeing similar behavior with the symlinks. rootfs/sbin/init for example points to /home/myuser/foo/rootfs/lib/systemd/systemd. If I try to do sudo chroot rootfs /sbin/init it fails with:
"chroot: failed to run command '/sbin/init': No such file or directory"
I get this failure with chroot on non-symlinks too though (ie "sudo chroot rootfs /bin/dash"), so I'm not sure these symptoms are related.
In short, I can't make a trasportable rootfs using fakechroot+debootstrap AND I can't use normal chroot with one either.
