Date: Sun, 18 Feb 2001 17:21:47 -0700 From: Wes Peters <wes@softweyr.com> To: Mark Murray <mark@grondar.za> Cc: Jordan Hubbard <jkh@winston.osd.bsdi.com>, arch@FreeBSD.ORG Subject: Re: Moving Things Message-ID: <3A90671B.AEE88134@softweyr.com> References: <11284.982487979@winston.osd.bsdi.com> <200102181055.f1IAt6957670@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Murray wrote:
>
> Step back and look at FreeBSD as ports and base combined - stir the pot
> if you will. Imagine a tree (use XML as a sort of concept here, although
> the final thing could be anything). At the concept level, this is NOT
> Makefiles, this is a configuration structure.
>
> There is a system that understands the above tree, and is able to use it
> to decide how to install software into the target system.
>
> Being a tree, this configuration structure is hierarchical - working
> from the base will result in more work being done than working from a
> branch or from a leaf. There would also be dependancies (installing
> (say) UUCP would depend on installation of any MTA).
I've been doing exactly this at work the past couple of weeks, and so will
share what we've come up with so far. I'll also point out the weaknesses
we see, and you all can point out the ones we haven't seen yet. ;^)
We started out in mid-December to build a few optional packages; things
our customers could buy and install after they have a DoBox in their home.
Some of our OEM customers may wish to pre-install some of these packages,
so we had to address the issue of making a package that could be installed
either on a running system (the way packages currently are) or on a
development system, installing into a DESTDIR.
Our system is in many way simpler than a generic FreeBSD installation, and
more complex in a few significant ways as well. Our configuration data
is stored in a database -- PostgreSQL currently -- which does not lend
itself to simply appending configuration data to a file somewhere.
All of our daemons processes are started via shell script in an rc.d
directory. We have extended these shells scripts to accept several more
"reason" arguments than the standard "start" and "stop." One new reason
is "init", which means this machine is in a "first birthday" boot, where
database tables may be added and populated, etc. The end-user will never
see this first birthday boot, it happens in the factory during the factory
acceptance test. This allows us to use the post-install script to prime
the database on a running system, or the rc.d script to do so if the
package is "factory installed".
We are currently defining the "release" process, which builds a system
image in a destination directory. What we have discussed so far is a
list of all the optional packages to install; the release process will
copy the "base system" into the destination, then install each of the
packages one by one.
Note: some of these packages are trivial, involving a few web pages for
the UI, others are quite complex. The one I just completed is a complete
mailserver, involving an MTA, POP/IMAP server, fetchmail, and some
custom glue to tie all of the above into our configuration database.*
One we defined this mechanism, we realized that much of what we consider
to be a "standard" part of our system could easily be extracted out this
way, making it simpler to offer our system to OEMs ala carte. We are in
the process of converting everything but the base OS to this framework
now.
Exactly what the "base OS" is is being re-defined on a daily basis, too.
So far, this system is working fairly well, though we keep finding little
bits that we have to re-address as we contemplate installing various
facilities both at system build time and on a running system. I'm sure
we'll run into some interesting conundrums as we confront upgrading
components in the field as well.
> At the small branch or leaf level, where individual bits are installed,
> there would be many ways to do things, depending on what you have, and
> what you want and need. A newbie would install compiled binaries, but
> a developer would check out sources, and compile/install those. Even
> developers may not be interested in all sources, and may choose to
> simply cache or download precompiled sources for things that they use
> but don't actively work on. All of this should be fluidly configurable.
>
> This way, the hardcore types can still to a "make world" (but can choose
> to leave out junk they don't like) while including in the build their
> favourite ("portish") tools (editors, servers etc).
In our system, "make world" builds everything, it is the release process
that selects one part or another. This would probably not be effective
for FreeBSD; we don't necessarily want to populate the source for every
package in the ports tree just to build the kernel.
* This one has to remain an end-user chosen option, due to the GPL on the
fetchmail code. If anyone knows of a fetchmail-like program under a more
usable license, I'd love to hear about it.
--
"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?3A90671B.AEE88134>