Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Apr 2001 19:19:53 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        rsidd@physics.iisc.ernet.in (Rahul Siddharthan)
Cc:        freebsd-chat@FreeBSD.ORG
Subject:   Re: ESR's CML2
Message-ID:  <200104101919.MAA28994@usr07.primenet.com>
In-Reply-To: <20010410172659.R14673@lpt.ens.fr> from "Rahul Siddharthan" at Apr 10, 2001 05:27:00 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> I was reading ESR's announcement of the 1.0 release of his
> CML2 (Configuration menu language), which he wrote for the
> linux kernel:
>   http://lwn.net/daily/cml2-1.0.php3
> The main web page of the project is at
>   http://www.tuxedo.org/~esr/cml2/
> 
> It looked interesting to me.  Is there any possibility that it
> could be used in FreeBSD, to make configuration easier for
> beginners?


I think the correct way to approach this is to move the needed
configuration intelligence into the module loader.

FreeBSD has some things which are configurable, but many of
them are actually redundant (NKPDE springs blithely to mind
as something that should be automatically determined based on
the kernel base relocation address, but isn't).

Most tunables are already tunable at load time, or even at
runtime.

The only things I see coming out of tuning is the ability to
make FreeBSD _not_ run on some hardware, for the dubious
benefit of not linking some drivers into the kernel, when the
drivers should be modules loaded at runtime, anyway.

IMO, configuration is a crutch that needs to be discarded.


> It seems to me that there are at least three things in FreeBSD which 
> could benefit from this:
>   (a) kernel configuration

See above.

>   (b) system installation
>   (c) the ports collection

I would lump these to together as "indistinguishable from each
other, in a properly designed installation management system".

The big problem with ports, IMO, is the increasing reliance on
GNU autoconfigure by software maintainers.  I really don't see
how this is properly addressed by ESR's new toy.


> The ports/packages collection does a good job of tracking
> dependencies, but there are problems.  The most common is when you are
> installing A, which depends on B version 1.2, but you already have B
> version 1.0.  If B 1.0 can be cleanly replaced with B 1.2, the system
> should just yank out B 1.0 altogether and replace it with B 1.2 (eg,
> upgrading from gtk 1.2.8 to 1.2.9) but if it cannot be simply
> replaced, it should install the two separately without conflict.
> Often it doesn't do the correct thing, and over a span of a year or so
> a lot of things can get messed up if you aren't careful.  Maybe it can
> even lead to a unified ports tree, with diffs based on which BSD
> you're running, or something?

This is really something which can only be loosely tracked, as
FreeBSD does not maintain all the code in ports, which makes it
harder when someone decides to change something.  Often, the
first the ports maintainers hear about it is when a version has
changed on a distribution file.

A good compromise approach to this would be to parse distribution
files for version information, and hope that the archive keeps at
least one revision going back, so that the version changes can be
screamed about to the user, who can then notify the port maintainer.

Really, I can't see a reasonable way to have automatically done the
right thing (whatever that is) for the KDE version 2.0 release (for
example).

There's also the concept of "preferred versions".  There are a lot
of ports with version numbers attached, to allow people to "prefer"
an older version.

Going back to the KDE example, if you were a twm user, you would
probably not consider KDE a "clean replacement" for your existing
desktop environment, even if you could be "upgraded" automatically,
with all dependencies handled.

I recently set up a build tree to build a product distribution out
of about 3.6 million lines of Open Source, and which could target
FreeBSD, Solaris, and AIX (as well as others; I just didn't do the
small number of Makefile changes to support other platforms).

With over 30 Open Source packages involved, and things like SSL
and perl existing on FreeBSD by default, but not elsewhere, I had
to do significant work.  I ended up with a six pass build process
that would let me build tools, libraries, tools, libraries, code,
and dependent code.  I could easily imagine that getting even more
complex, the more things I added to the mix.


> I don't know how easily such problems can be addressed with Raymond's
> scheme or what sort of work is already going on, but this looked like
> an interesting thought, anyway.  I may have some spare time in summer
> to play around with such things.

IMO, ESR's CML is a toy.  You could achieve the same thing with
"make" and probably be happier with it.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104101919.MAA28994>