Date: Tue, 27 Feb 2001 13:36:49 +0200 From: Mark Murray <mark@grondar.za> To: arch@freebsd.org Subject: FreeBSD sources from 20000' Message-ID: <200102271136.f1RBa4R12865@gratis.grondar.za>
next in thread | raw e-mail | index | archive | help
Hello all. There was a pretty good response to my initial probe a few days ago, so the time comes by to revive the discussion, and to slowly begin on the path to an actual solution. REMINDER REMINDER - The whole point of this exercise is NOT to remove ANYTHING from FreeBSD. Effectively, FreeBSD will become a grow-only system with the configuration and installation policies placed in the hands of the owners or sysadmins. By "grow-only", I do not mean we cannot throw out the trash; it just means that arguments such as "please don't remove UUCP" or "please remove the r-utils" are largely irrelevant. REMINDER REMINDER - I am going to be giving a lot of "real life" examples here to attempt to make the explanation understandable - PLEASE do not bikeshed those examples. OK - lets take a look at what we have. FreeBSD is divided into 3 pieces in the repo - "base" (or src/), "ports" and "doc". Consider that division to be removed completely (by some mechanism to be discussed below), and look at FreeBSD as a collection of what CVS would call "modules". Examples of modules are as diverse as "uucp"(src/gnu/libexec/uucp), "ls"(src/bin/ls), "perl5"(src/contrib/perl5), "epic4"(ports/irc/epic4), "kernel"(src/sys), "randomdev"(src/sys/modules/random), "handbook"(doc/mumble/handbook) and so on. Some modules can almost "build themeselves" - autonomous ports and the ordinary BSD stuff like ls(1) or cat(2) are examples of this. Some modules need a little help - kernel modules require kernel source to build, most modules require a minimum toolchain, and some need specialised tools (like the kernel needs config(8) and doc/ needs tons of ports). So - doing a coarse sort of all the modules in freebsd, we end up with a selection of categories loosely looking like this: 1) "base" module currently in FreeBSD CVS repo. (eg: ls(1), cat(1)). 2) "contrib" module currently in FreeBSD CVS repo, externally maintained but "tightly bound" to FreeBSD (eg: perl5, gcc, kerberos, OpenSSH). 3) "KLD" kernel module. (eg: random.ko) 3a) "kernel" all of kernel and includes kernel modules. (src/sys/...) 4) "port" "external" software not built during a "make world". (eg: ports/games/gnuchess) 5) "doc" Documentation that needs SGML-work to be useful. (eg: "English handbook", "Japanese FAQ"). 6) "set" holds other modules (eg: src/bin/, secure/, sys/modules/, "Japanese docs" ports/shells/). I have no doubt missed some. More will crawl out of the woodwork as we work on this, and the borders and subclasses will get redefined. To work on that fine detail now is not useful. Now, we need an understanding of the relationship and use of these modules. Imagine a configuration tree (I am going to use an XML-like metalanguage here for illustration) that takes something like our current repository as input, and builds a tree four output. What that tree is, depends on who the user is and what they want. Example - for ls: <module name=ls distribution=bin> <source type=CVS location=src/bin/ls makefile=BSD> <bin destdir=/bin> ls </bin> <doc type=mdoc destdir=/usr/share/man compress=gz> man1/ls.1 </doc> </module> - for emacs: <module name=emacs distribution=emacs defaultprefix=/usr/local> <source type=FTP location=ftp.emacs.org/pub/ checksum=40985039485> emacs.tar.gz <source> <patch type=CVS location=ports/editors/emacs> workdir/emacs/foo/bar.c.patch workdir/emacs/baz/qux.c.patch </patch> <build type=gnu> <bin destdir=bin files="emacs,info"> emacs info <bin> <doc type=man destdir=man compress=gz> man1/emacs.1 </doc> <doc type=info destdir=man compress=gz> emacs.info emacslisp.info </doc> <data destdir=share/emacs> emacs.help </data> </module> Each of these would have a radically different behaviour for a developer, and a substantially similar behaviour for an end user. For the end user, an "install this please" would simply mean installing the compiled binary and manual pages using the most expedient method. That could mean a download, or reading the relevant files off a CD. For a developer, however, the whole process may involve a CVS checkout/update and a build before installation for ls. Emacs would need a download, a verification, untar, patch, configuration and build (like current ports). A "clean up please" would do nothing for a user. For developers, It would blow away generated crap (.o's and so on) for ls, and the whole untarred build area for emacs. "Uninstall this please" would behave identically for the developer and the user - the relevant "installed bits" would get removed. The distinction between "developer" and "user" should not be taken overly seriously at this stage; kernel hackers may want a binary install of CURRENT to be done automatically - this needs to be possible. Containment (or "set") modules will be structured kinda like so: <module name=bin distribution=bin attribute=static> <submodule> cat ls echo sh </submodule> </module> NOTE NOTE - this specifically allows the user to choose to compile what they want where they want. (EG: nothing prevents the "port" ports/shells/bash2 from being compiled as a part of /bin/*). Other possibilities will include the ability to not include certain parts in "MyBSD". Don't want Perl5? You don't have to include it in your build/install. This would require that the user types are profiled, and that common ones are made easily selectable. Types may include "user", "dialup user", "graphics user", "audio user", "Apache server", "MySQL server", "kernel hacker", "X/KDE hacker", "X/Gnome hacker", "[X]Emacs hacker", "Utils hacker", "Perl Hacker", "Crypto Hacker", "Kerberos Hacker", "Apache hacker" and so on (all of them tweakable, and some of them capable of sub or multiple categories). OK. End of this thought-dump. Who's coming to play? M -- Mark Murray Warning: this .sig is umop ap!sdn 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?200102271136.f1RBa4R12865>