Date: Tue, 06 Jul 1999 11:33:30 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: emulation@FreeBSD.ORG Subject: FYI: Linux emulation: what, how, when, why, who, where Message-ID: <3781CD6A.B221831E@scc.nl>
next in thread | raw e-mail | index | archive | help
Hi, I hereby give you all an outline of what I'm planning to do, why am doing it, how I intend to get away with it, when it's important to get it done and last but not least, where I'm planning to hide after I've done it :-) I've now made 2 changes: A) ELF loader so that dynamicly linked Linux binaries can be used in a chroot'd environment, with /compat/linux as the new root, and B) the uname syscall. It now returns "Linux" as the OS name. These two changes are the basis for: C) importing the new linux_lib replacement, which I inted to call linux-base-5.2 because 1) it not only contains libs 2) it's a subset of a RH base installation and 3) The RH release is 5.2. A is important for C because I intend to use the RPM port, which is a FreeBSD native binary, and I need the --root option which results in a chroot. B is important for C, because it enables me to use the Linux native RPM (which gets installed in the process) to do installations. Let FRPM be the FreeBSD native RPM with the chroot issue, and Let LRPM be the Linux native RPM with the uname issue. After C comes: D) import of the linux_devel replacement, which I intend to call linux-devel-5.2. Don't ask why :-) Having both A and B has the advantage of C being setup so that D can be installed by FRPM and/or LRPM. Using FRPM to install D has the disadvantage that C must include enough to support RPM post-install scripts in a chroot's env. This include /tmp, /dev/null, /var/tmp and so on. This breaks lots of cases where Linux binaries use FreeBSD binaries and passing them filenames (such as printing from a Linux Netscape). Using LRPM to install D has no drawbacks that I can think of right now and is the rpm by choice for the moment. So, why A and FRPM, I hear you say? Simply because FRPM is the one that is in everybodies PATH and just entering something like rpm -i foobar.rpm to add a new package is what I like to accomplish. And since FRPM is a port, I can't just deinstall it and make a link to LRPM somewhere in the PATH. Why not? Because I need FRPM for the deinstall of C and I can't force a user to not use the RPM port. There's another reason, but that's for later. So, up to this point, I have imported the new ports, the next step is E) Update any linux dependent ports so that they work with the new ports. This only involves dependencies for most ports, but it is possible that some ports can be changed to use rpm distfiles and let these get installed by using eith FRPM or LRPM. LRPM by default for now. After E follows F, but it's not determined what F should be. There's a lot that can be done... [end of part 1] -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ Amsterdam, The Netherlands tel: +31 20 4200655 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3781CD6A.B221831E>