From owner-freebsd-emulation Wed Feb 3 16:06:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA24302 for freebsd-emulation-outgoing; Wed, 3 Feb 1999 16:06:36 -0800 (PST) (envelope-from owner-freebsd-emulation@FreeBSD.ORG) Received: from dingo.cdrom.com (castles240.castles.com [208.214.165.240]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA24186 for ; Wed, 3 Feb 1999 16:06:27 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA09939; Wed, 3 Feb 1999 16:02:13 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902040002.QAA09939@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Marcel Moolenaar cc: emulation@FreeBSD.ORG Subject: Re: Linux collections (was: Linux devel doesn't work with glibc libs) In-reply-to: Your message of "Thu, 04 Feb 1999 00:24:22 +0100." <36B8DAA6.B5BF232E@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Feb 1999 16:02:13 -0800 From: Mike Smith Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Currently I don't use the ports-collection. I've downloaded Red Hat 5.2 > > > packages and installed them. > > > > This is exactly what I think the port should do. Ie., it should > > proceed as follows (in the case where nothing is already installed) > > > > - Ensure that the Linux emulator is already running. > > Check. > > > - Download and install the current RedHat RPM binaries. > > I prefer the RPM port for the following reasons: > 1. It is easier. Not notably. > 2. Releases and updates of RPM are independent of Red Hat releases. This is bad. We want to be 100% in sync with the release we're trying to emulate. > 3. We cannot satisfy any possible configuration with only a few prefab > collections; so we can expect users to want to install individual packages > too. A FreeBSD native rpm is more pleasant to use than an emulated one. It's not notably different, actually. Now the downsides to using the FreeBSD RPM: - it's not installed in /bin. That's where RedHat puts it, and it's where anything that interacts with the RedHat package database wants it. (eg. The IBM DB2 installer). - its databases don't end up in the canonical place (because that would be stupid on FreeBSD). - it doesn't run in Linux compataility mode, so it won't see things in the /compat/linux tree, nor will it install things there. There's basically no good reason to use the FreeBSD RPM port, and lots of good reasons not to. I went through the process of evaluating both approaches while I was trying to get DB2 installed, and while the RedHat binary doesn't work 100% right either, the FreeBSD binary was definitely going to lead to more heartache. > > - Download and install (using the just-installed RPM) the various RPMs > > that Linux applications these days are requiring. > > This is the hard part. I think we're better off with more than two > collections, because that would scales better (especially for small > installations). We also benefit from the dependency information stored in the > port. There's no hope that Linux emulation is going to work well in a "small installation". We also don't want to limit people to just what's available already in the ports collection. We should aim for a fairly comprehensive base library set, and yes, make it easy for ports to add extra stuff as required. > > The linux-devel port should have the linux-lib port as a prerequisite, > > and should again use the Linux RPM to install the development RPMs. > > What about the following collections (as a start): > > Linux: basic runtime environment (whatever we define it :-) > Linux-devel: basic development env. (needs Linux) > Linux-X11: X runtime environment (needs Linux) This should probably be part of the basic runtime. > Linux-X11-devel: X development env. (needs Linux-devel) Just as this should be part of the basic development environment. > linux-ports: FreeBSD ports of linux-specific tools (such as ps(1)) (needs > linux) If just installing the RPM is enough, these should be in the runtime. If they're from-source ports, then they want to be separate, indeed. The question here is whether they should be FreeBSD binaries installed in /compat/linux, or whether they should be build using the linux compatibility code. Ick. Wherever possible we should extend our emulation so that the Linux-native tools work of course. > > If you feel like you can undertake this, start small; just pick four or > > five RPMs and make the Makefile and packaging work. Get back to us/me > > here if you need any help. > > Ok. Feedback time :-) > > 1. I'll start with the basic (bare minimum), and call it Linux (as to > preserve the current ports)... > 2. I'm going to use the RPM port as the sole dependency... See above on this. > 3. linux.ko is loaded if necessary... Don't load it; just complain if it's not loaded. Loading it may kill the system if the emulator is out-of-version. > 4. It is going to contain just enough packages to have a Linux bash > installed. To be precise: > setup-1.9.2-1.noarch.rpm > filesystem-1.3.2-3.noarch.rpm > basesystem-4.9-3.noarch.rpm > ld.so-1.9.5-8.i386.rpm > ldconfig-1.9.5-8.i386.rpm > glibc-2.0.7-29.i386.rpm > termcap-9.12.6-11.noarch.rpm > zlib-1.1.3-2.i386.rpm > mktemp-1.4-3.i386.rpm > libtermcap-2.0.8-10.i386.rpm > bash-1.14.7-13.i386.rpm > 5. Other collections (to be defined) build upon the 'Linux' collection (see > my suggestion of other collections)... I'd KISS for now; just runtime and development. The development stuff is enormous of course (tools, includes, static libs, manpages, etc.), but the runtime won't bloat all that badly even with the X stuff installed. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message