Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Feb 2001 22:45:33 -0700
From:      Wes Peters <wes@softweyr.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        arch@FreeBSD.ORG
Subject:   Re: Moving Things [was Re: List of things to move from main tree]
Message-ID:  <3A90B2FD.68EDC2E1@softweyr.com>
References:  <200102190515.WAA12356@usr05.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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/<foo>/lib" as "the 
place where all libraries installed from packages are found", I don't
see any issue other than making sure "/usr/<foo>/lib" is in ld.so's
path.

I refuse to participate in discussions of the value of <foo> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A90B2FD.68EDC2E1>