From owner-freebsd-arch Sun Feb 18 21:47:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5BE9937B69E for ; Sun, 18 Feb 2001 21:43:54 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Uj8f-0000PP-00; Sun, 18 Feb 2001 22:45:33 -0700 Message-ID: <3A90B2FD.68EDC2E1@softweyr.com> Date: Sun, 18 Feb 2001 22:45:33 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <200102190515.WAA12356@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > If XML is going to be used during install, maybe it'd be a good > > > idea to build a small LALR parser, which only knows about the > > > grammar to be used for the specific application. > > > > Expat helps build such parsers. The syntax is slightly weird, but it's > > a lot smaller than 5.5 MB. > > Writing a parser is trivial, even if you don't use lex/yacc or some > other tool to do it. It's not really as interesting to talk about > the implementation details as it is to know that a pure XML parser > bent into an install tool is probably way too large for a floppy. Uh, yeah. There is the added benefit that I can provide source to several fairly simple parsers written with Expat, and the license is reasonable. > > I think the idea is push everything that cannot be considered a core > > part of the operating system into a different part of the tree, that > > can be chosen from ala carte. This is a lot more extensive than > > moving games to the ports tree. Telnet, ftp, rtools, UUCP, sendmail, > > DNS, etc. > > That's fine, but we don't need to move it around in the repository, > lose its history, and add gigabytes to the attic. I'm less concerned with disk space on the CVS server (and backups) than I am with modularizing the build system. > > The package dependency mechansim helps take care of that. If you > > select a package that requires a shared library you don't have, the > > dependency will install the shared library package as well. > > The problem is more that, once something is linked against a > shared library, moving the library around is not really an > option. Nor should it be necessary. Each library has one and only one home; if we want to define "/usr/lib" as "the place where the libraries shipped with the base system are found" and "/usr//lib" as "the place where all libraries installed from packages are found", I don't see any issue other than making sure "/usr//lib" is in ld.so's path. I refuse to participate in discussions of the value of because it just doesn't matter. > Speaking of which, is anyone else incredibly annoyed > that ld.so doesn't search for things not in the ldconfig cache? Yes. > My personal experience is similar to what you said your company > had been doing for builds. I have a 6-pass build process that > builds a lot of open source stuff, and a lot of my own stuff, > and then builds distribution packages out of it. There is a > seperate package for each server role. Obviously, you could > install all the distributions onto a single box (makes a good > demo system, except you can't demostrate data replication), but > typically you would set up a data center so that you had each > role on a seperate machine, and two or more machines for each > role. Yup. Let me know if you want some pointers on low-cost small computers for demo machines. > The point of this is that it's much more logical to think of > configuration management in terms of the roles you expect a > machine to take, and that, at least for users, the important > thing is to be able to choose binary sets to install (or not), > cafeteria style. That may mean you can't get a ham sandwich > without also getting mustard, unless you pick the "custom" > option, and dick with the details. Having a template works > best (e.g. "Ham sandwitch without mustard" is better than > "bread, ham, lettuce, swiss cheese, mayonaise, tomato"). Right. A design goal should be to make it relatively simple to let skilled system administrators put together their own definitions, and some way to add these definitions into an install medium. Collecting a large set of these and adding them to the base install seems like a good idea, too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message