[gentoo-dev] Gentoo installed, thoughts

[James Vandenberg]

Hi,

I recently installed Gentoo Linux, and I must say I was impressed with what
I saw. I'm finally able to have a completely optimised system out of the
box.  Apart from a few stupid mistakes on my part, (Forgetting to uncomment
the USE line in make.conf, leading to 3dnow and sse being compiled into X,
which I don't have and consequently needing to recompile X. This is on a
PII-266.  S-l-o-w!) and the abrupt rsync transition, I had a fairly
comfortable install.

It'd be nice though if those bootstrap phases could be automated. It'd be
cool to be able to generate a `reinstall' CD from a working gentoo system,
and then when disaster strikes, stick it in, go do something else, and have
the system almost back to normal, apart from restoring from backups.

I previously used Debian as my primary desktop distro, but I got fed up by
its slow pace, both in development and in operation. I have a Pentium, not
a 386, dammit! But there are a few ideas in Debian that almost make up for
it's drawbacks. I think Gentoo should steal, er, borrow these ideas.
Homework permitting, I'll try and have a proof of concept, possibly in a
month or two.

The idea Gentoo should steal is a generalisation of Debian's `menu' system.
The problem this package tries to solve can be generalised to other
situations, such as inetd daemons, byte-compiling emacs .el files, fonts
and netscape style plugins. The general case of the problem is that of
transforming many data fragments from a common, package provided format
into many formats specific to particular packages. Like transforming menu
entries into window manager configuartion files, or elisp programs into
byte-compiled versions for emacsen, or inet daemon descriptions into
inetd.conf or xinetd.conf.

The goal is to make a set of programs that can deal with this sort of
situation in a general way, so that it can be extended to new situations
without too much difficulty.

Packages that provide fragments of data, such as menu entries, might be
called producers, and those that use the fragments to create a complete
configuration are consumers. There may be other programs that modify the
fragment before it reaches the consumer, call them tinkerers. The fragments
of data would be called products. So a producer creates a product which is
modified by tinkerers and then used by a consumer.

The producer is very simple. Given the product and its type by the
package's .ebuild, it would run the following psuedocode (or something
similar):

for each tinkerer of type,
	pass product through tinkerer into transformed
	for each consumer of type,
		pass transformed to consumer
	end
end

Or, if a new consumer is installed,

for each product of type,
	for each tinkerer of type,
		pass product through tinkerer into transformed
		pass transformed to consumer
	end
end

Products themselves are sort of object-oriented. That is, a product defines
a number of fields, such as "name of elisp file", or "menu hierarchy
locataion" or "in.server program". Product types can inherit from each
other.  There would also be a base type, which provides some basic fields.
These might be type, version of type, providing package.

Tinkerers would be somewhat like `awk' programs, but running on product
records, and not lines in a file. An example of a tinkerer would be
transform of menu records for users, so that users can customise their own
menus to suit their taste. 

Not all tinkerers may use configuration files, or do per-user tinkering
(Inetd, frinstance), and the syntax would be different for each, although
using shell scripts with bash functions defined to do operations on the
product would be the most flexible.

Once tinkerers have transformed the products, they are fed to consumers.
Consumers transform the products into configuration or data files specific
to the package that installed them. However for each type, they will share
a common parser for the products. This should probably be provided by the
same package that provided the type description.

Finally, there would be a few support programs for tasks such as installing
new types, or testing consumers or tinkerers. This system would solve a
number of problems that most distributions appear to experience. In
Debian's case, the same problem was solved by a number of different
programs, such as menu, emacsen-common and defoma.

If it weren't for University, this would be less vapourous. I'd try and get
this programmed. As it is, I'll just have to do what I can in the time I do
have.

Also, looking at the portage2 docs, it seems to me like the USE flags
system is heading towards something resembling Debconf. Debconf has some
very cool aspects, but it also has some weak spots as well. Personally, I'd
like to see some combination of USE and Debconf, like Portage is a cross
between Ports and apt-get. 

Anyway, thanks for Gentoo. It's really rather nifty. I'd like to contribute
a lot to it, since it looks like it'll be fun. It'll also be my way of
repaying the Open Source community for letting me use Linux and friends.

Ja-emerge-a-new-os-today!-mes
-- 
James Vandenberg Email: james at vandenberg.dropbear.id.au
GPG FP= 65AB 179A D884 EDC6 216D  FE6A 6833 02BC 4425 4F70
Quidquid latine dictum sit, altum viditur.  ICQ: 151135390