On Tue, Feb 27, 2001 at 09:41:38AM +1100, Brian May wrote: > Marcus> It should be possible to make fakeroot work if it doesn't > Marcus> already out of the box. I think the reason that prevented > Marcus> me from looking at it was that the build process required > Marcus> getopts from util-linux, and I hadn't made a crufty > Marcus> util-linux package back then. I would encourage you to try > Marcus> it. > > I can't get either sudo or fakeroot to work. > > sudo: won't accept my root password.
You will have to debug it. Maybe it is something simple like a missing suid flag, maybe it is a bug. > fakeroot: requires g++ which in turn requires libstdc++2.10-dev, which > doesn't seem to be compiled yet. I am sure you can work around this with some force-depends or other stuff (configuring g++ and libstdc++2.10-dev in one run or so). > Marcus> It's quite easy: task devel packages suffer from similar > Marcus> linuxisms as other packages depencies. > > Solutions? uh, contact the task package maintainer. Maybe we need architecture specific task packages, or a suggests rather than a dependency, or architecture specific task packages. Or (finally) we will have all-linux and all-hurd, and make a different task package for all-linux or all-hurd. I don't know what's the best solution is for task packages. > Ok. Good. > > Marcus> If you'd really want this feature in a filesystem, you'd > Marcus> add another RPC which would tell the filesystem server to > Marcus> set itself as the translator on a certain node. (Or just > Marcus> pass the port directly). But I don't think it is too > Marcus> useful a feature. What's the difference between mounting > Marcus> several times and just setting symlinks? [1] [2] > > symlinks, AFAIK, don't work in a chroot environment. I suspect as much. But then, a mount also only works for root in Linux. It might be quite easy to write some special symlink like translator which could run as root in a chroot environment and get around the limitation, but I have no clear vision on how to do that right now (you'd have to set it up in a very specific way, because a chroot is actually about dropping references to parent directories, and for this special translator, you need to keep a port to the file system image or the parent directories). I am not sure this mixes well with the chroot concept. In any way, chroots are lame. In the Hurd, you can boot a complete sub hurd as an arbitrary user, and with shadowfs you will have a convenient way to not start from scratch but from the root filesystem. > Marcus> [1] In Linux, you don't get "sub mounts", in fact, there > Marcus> is nothing like a submount in linux. In the Hurd, you > Marcus> would always get the "submounts". To not get them, you'd > Marcus> need to take special precautions, and it would be quite > Marcus> impossible to do this cleanly, because even symlinks might > Marcus> just be implemented as translated nodes (see "showtrans > Marcus> /usr" for a faked example). > > I am not familiarly with sub mounts (at least the terminology), what > do they allow you to do? Well, I invented the terminology when writing the above paragraph. You should forget it immeidately ;) In the Hurd, there is no central "phone book" of all filesystem servers. Instead, every filesystem keeps a list of ports to filesystem servers attached to a node in the specific filesystem it provides. When you have a pathname resolution, the C library first queries the root filesystem server with the full path. The prefix the root filesystem can resolve is stripped, and a port to the next server returned together with the remaining path component. The C library then retries the lookup. So if you ask to open the file /mnt/mnt2/readme.txt, and mnt is a mounted filesystem, and mnt2 another mounted filesystem, it goes like this: C lib: "Hey, root fs, what's /mnt/mnt2/readme.txt?" root fs: "dunno, but ask this port [mnt fs] for /mnt2/readme.txt" C lib: "Hey, port [mnt fs], what's /mnt2/readme.txt?" mnt fs: "dunno, you should ask this port [mnt2 fs] for readme.txt" C lib: "Hey, port [mnt2 fs], what's /readme.txt?" mnt2fs: "no such file or directory" or "this port is the file port you want". So, before explicitely asking for a path name, the C library will not know which filesystem server to query about. So we actually have a tree of "phone books" (every filesystem server keeping a full list). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
