From owner-freebsd-chat Tue Apr 10 12:21:13 2001 Delivered-To: freebsd-chat@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 270CE37B43E for ; Tue, 10 Apr 2001 12:21:09 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id MAA02758; Tue, 10 Apr 2001 12:21:06 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp05.primenet.com, id smtpdAAAGGaGJe; Tue Apr 10 12:19:51 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id MAA28994; Tue, 10 Apr 2001 12:19:59 -0700 (MST) From: Terry Lambert Message-Id: <200104101919.MAA28994@usr07.primenet.com> Subject: Re: ESR's CML2 To: rsidd@physics.iisc.ernet.in (Rahul Siddharthan) Date: Tue, 10 Apr 2001 19:19:53 +0000 (GMT) Cc: freebsd-chat@FreeBSD.ORG In-Reply-To: <20010410172659.R14673@lpt.ens.fr> from "Rahul Siddharthan" at Apr 10, 2001 05:27:00 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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