[gentoo-dev] apache.eclass proposed

[gentoo-dev] apache.eclass proposed

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

After writing a net-www/ ebuild it seemed apparent to me that we are
going to need an apache.eclass. A quick find in portage reveals quite a
few independent ebuilds all needing the basic functionality that could
be provided by an apache.eclass

syntactically perfect the idea is what matters..
I have attached an apache.eclass that I welcome your input/feedback on.
While it may not be syntactically perfect for the apache2 part its the
idea that we get this out there and start talking about one that
matters.

my portage # find . -name '*.ebuild' | xargs grep HTTPD_USER= | wc
     22      96    1904
my portage # find . -name '*.ebuild' | xargs grep HTTPD_GROUP= | wc
     21     123    2081
my portage # find . -name '*.ebuild' | xargs grep HTTPD_ROOT= | wc
     50     299    5154
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux (Hardened)

[-- Attachment #2: apache.eclass --]
[-- Type: text/plain, Size: 2326 bytes --]

# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Author: Ned Ludd <solar@gentoo.org>
#
# This eclass is designed to allow easier installation of web applications,
# modules, and their counterparts incorporation into the Gentoo Linux system.
# 

#set -x

ECLASS=apache
INHERITED="${INHERITED} ${ECLASS}"
IUSE="apache2 ${IUSE}"
DESCRIPTION="Based on the ${ECLASS} eclass"

newdepend virtual/glibc sys-apps/gawk sys-apps/grep 
#	apache2? ( >=net-www/apache-2.0.43-r1 ) \
#	!apache2? ( !<net-www/apache-1.3.26-r2 <net-www/apache-2 )"
#

EXPORT_FUNCTIONS has_apache2 httpd_getvar httpd_user httpd_group httpd_root

# Return the string 2 on success, nothing otherwise
has_apache2() {
	ret="";
	# The use flag overrides all.
	if [ `use apache2` ]; then
		ret=2
	else
		if [ `has_version '>=net-www/apache-2'` ]; then
			# If user has apache 1 & 2 installed and use  
			# `use apache2` was not set then we should pref apache1
			if [ `has_version '<net-www/apache-2'` ]; then
				ret=""
			else
				ret=2
			fi
		fi
	fi
	echo -n "${ret}"
}

# Wrapper function to grep for string from file. 
httpd_getvar() {
	name=$1
	conf=$2
	[ ! -f "${conf}" ] && die "$conf: No such file or directory"
	v=$(grep ^${name} ${conf} | gawk '{print $2}' | head -1)
	echo -n "${v}";
}

# Get apache User / should return apache
httpd_user() {
	ap=$(has_apache2)
	conf="/etc/apache${ap}/conf/commonapache${ap}.conf"
	httpd_getvar User ${conf}
}

# Get apache Group / should return apache
httpd_group() {
	ap=$(has_apache2)
	conf="/etc/apache${ap}/conf/commonapache${ap}.conf"
	httpd_getvar Group ${conf}	
}

# Get apache DocumentRoot
httpd_root() {
	ap=$(has_apache2)
	conf=/etc/apache${ap}/conf/apache${ap}.conf
	httpd_getvar DocumentRoot ${conf}
}

httpd_user=`httpd_user`
httpd_group=`httpd_group`
httpd_root=`httpd_root`

# fallbacks
[ -z "${httpd_user}" ] && httpd_user="apache"
[ -z "${httpd_group}" ] && httpd_group="apache"
[ -z "${httpd_root}" ] && httpd_root="/home/httpd/htdocs"

# Mark readonly so other ebuilds dont override.
declare -r HTTPD_USER=${httpd_user};
declare -r HTTPD_GROUP=${httpd_group};
declare -r HTTPD_ROOT=${httpd_root}

export HTTPD_USER
export HTTPD_GROUP 
export HTTPD_ROOT

unset httpd_user
unset httpd_group
unset httpd_root

#set +x


[-- Attachment #3: Type: text/plain, Size: 37 bytes --]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache.eclass proposed

[Joshua Brindle]

This is very good, I've seen many apache related ebuilds that do 
not do the right thing about determining what apache/which configs
which directories, etc to use, I think that all apache related ebuilds
should use this, it's an easy and central way to manage the logic
of apache configs

Good job solar :)


>After writing a net-www/ ebuild it seemed apparent to me that we are
>going to need an apache.eclass. A quick find in portage reveals quite a
>few independent ebuilds all needing the basic functionality that could
>be provided by an apache.eclass
>
>syntactically perfect the idea is what matters..
>I have attached an apache.eclass that I welcome your input/feedback on.
>While it may not be syntactically perfect for the apache2 part its the
>idea that we get this out there and start talking about one that
>matters.
>
>my portage # find . -name '*.ebuild' | xargs grep HTTPD_USER= | wc
>     22      96    1904
>my portage # find . -name '*.ebuild' | xargs grep HTTPD_GROUP= | wc
>     21     123    2081
>my portage # find . -name '*.ebuild' | xargs grep HTTPD_ROOT= | wc
>     50     299    5154
>-- 
>Ned Ludd <solar@gentoo.org>
>Gentoo Linux (Hardened)


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache.eclass proposed

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

On Sun, Jun 08, 2003 at 06:12:21AM -0400, Ned Ludd wrote:
> After writing a net-www/ ebuild it seemed apparent to me that we are
> going to need an apache.eclass. A quick find in portage reveals quite a
> few independent ebuilds all needing the basic functionality that could
> be provided by an apache.eclass
I agree that having this would be worthwhile, however it has been said
higher up before that /home/httpd/htdocs would be where things were
installed.

> syntactically perfect the idea is what matters..
> I have attached an apache.eclass that I welcome your input/feedback on.
> While it may not be syntactically perfect for the apache2 part its the
> idea that we get this out there and start talking about one that
> matters.
A few problems with this.
1. What about people that have both installed? I actually have an open
bug for mod_php about this, and I'm trying to decide on a workable
solution. Presently I'm leaning towards an enviroment variable
'FORCE_APACHE=1|2' that overrides any detection routines, for the
special case of people that have both.

2. All of the functions start misbehaving when you have multiple
instances of the User/Group/DocumentRoot configuration directives.

3. The 'newdepend  virtual/glibc sys-apps/gawk sys-apps/grep'
is questionable.
newdepend is definately correct for the apache install,
however the others shouldn't be required at runtime.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] apache.eclass proposed

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1755 bytes --]

On Sunday 08 June 2003 21:45, Robin H.Johnson wrote:
> On Sun, Jun 08, 2003 at 06:12:21AM -0400, Ned Ludd wrote:
> > After writing a net-www/ ebuild it seemed apparent to me that we are
> > going to need an apache.eclass. A quick find in portage reveals quite a
> > few independent ebuilds all needing the basic functionality that could
> > be provided by an apache.eclass
>
> I agree that having this would be worthwhile, however it has been said
> higher up before that /home/httpd/htdocs would be where things were
> installed.
>
> > syntactically perfect the idea is what matters..
> > I have attached an apache.eclass that I welcome your input/feedback on.
> > While it may not be syntactically perfect for the apache2 part its the
> > idea that we get this out there and start talking about one that
> > matters.
>
> A few problems with this.
> 1. What about people that have both installed? I actually have an open
> bug for mod_php about this, and I'm trying to decide on a workable
> solution. Presently I'm leaning towards an enviroment variable
> 'FORCE_APACHE=1|2' that overrides any detection routines, for the
> special case of people that have both.

This is what the apache2 use variable is supposed to do. At least, as far as I 
know.

>
> 2. All of the functions start misbehaving when you have multiple
> instances of the User/Group/DocumentRoot configuration directives.
>
> 3. The 'newdepend  virtual/glibc sys-apps/gawk sys-apps/grep'
> is questionable.
> newdepend is definately correct for the apache install,
> however the others shouldn't be required at runtime.

I agree with both points.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] apache.eclass proposed

[Ned Ludd]

First I'd like to say sorry to the ml this should of been called an
apache.eclass draft.

On Sun, 2003-06-08 at 15:50, Paul de Vrieze wrote:
> On Sunday 08 June 2003 21:45, Robin H.Johnson wrote:
> > On Sun, Jun 08, 2003 at 06:12:21AM -0400, Ned Ludd wrote:
> > > After writing a net-www/ ebuild it seemed apparent to me that we are
> > > going to need an apache.eclass. A quick find in portage reveals quite a
> > > few independent ebuilds all needing the basic functionality that could
> > > be provided by an apache.eclass
> >
> > I agree that having this would be worthwhile, however it has been said
> > higher up before that /home/httpd/htdocs would be where things were
> > installed.
> >
What about the users that are changing there default DocumentRoot's?
Are we to ignore that completly and install to /home/httpd/htdocs
anyway?

> > A few problems with this.
> > 1. What about people that have both installed? I actually have an open
> > bug for mod_php about this, and I'm trying to decide on a workable
> > solution. Presently I'm leaning towards an enviroment variable
> > 'FORCE_APACHE=1|2' that overrides any detection routines, for the
> > special case of people that have both.
> 
Such and enviroment variable would make things quite less complex.

> This is what the apache2 use variable is supposed to do. At least, as far as I 
> know.
It does not behave this way for me, try USE=-apache2 with KEYWORDS=~x86
while wanting to keep an apache2 from getting installed.

Aparently the apache2 use flag was introduced to break the tie if both
apache 1 and apache 2 were installed but very few people are using it
correctly though, thus the need for these things to be addressed by an
eclass vrs everybodys the ebuilds themselfs.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux (Hardened)


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache.eclass proposed

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]

On Sun, Jun 08, 2003 at 11:07:49PM -0400, Ned Ludd wrote:
> > > I agree that having this would be worthwhile, however it has been said
> > > higher up before that /home/httpd/htdocs would be where things were
> > > installed.
> What about the users that are changing there default DocumentRoot's?
> Are we to ignore that completly and install to /home/httpd/htdocs
> anyway?
I believe that would be a better solution than looking for the
DocumentRoot they have set. As an example, I run a couple of webservers
at work. Their DocumentRoot is /var/www, which is a read-only NFS mount.

I'd venture that those users than change the DocumentRoot are doing so
for a very specific reason.

One further thing with the DocumentRoot issue. Say I have two systems
that share binary packages, but they have different DocumentRoot
settings. I create the binary tbz2 on the first system, and it packages
everything up with the first path, say /home/httpd/htdocs. Then I want
to also install on the second system, which has a DocumentRoot of
/var/www. The files would still be installed to /home/httpd/htdocs,
defeating the purpose of your check for the DocumentRoot setting.

What I do on my systems presently, (that don't have DocumentRoot as a RO
nfs mount in /var/www) is let all ebuilds install to the
/home/httpd/htdocs, and then symlink them into my own DocumentRoot
location.

On the same note with DocumentRoot, having Apache installed explictly
implies a User of 'apache' and Group 'apache' existing. Rather than any
magic on this, lets install all default packages with that uid and gid,
and instead work on keeping that secure. If users change the User and
Group setting in Apache again, they usually have a _very_ good reason
for doing so, and so should be able to deal with the concequences
themselves.

> > > A few problems with this.
> > > 1. What about people that have both installed? I actually have an open
> > > bug for mod_php about this, and I'm trying to decide on a workable
> > > solution. Presently I'm leaning towards an enviroment variable
> > > 'FORCE_APACHE=1|2' that overrides any detection routines, for the
> > > special case of people that have both.
> Such and enviroment variable would make things quite less complex.
Ok, could we possibly come up with something that everybody can agree
on, and then use that everywhere.

> > This is what the apache2 use variable is supposed to do. At least, as far as I 
> > know.
> It does not behave this way for me, try USE=-apache2 with KEYWORDS=~x86
> while wanting to keep an apache2 from getting installed.
The apache1/2 stuff on ~x86 is a mess, I strongly agree there.
I'd really like it if apache1 just went away, but I see some users want
it for various reasons.

> Aparently the apache2 use flag was introduced to break the tie if both
> apache 1 and apache 2 were installed but very few people are using it
> correctly though, thus the need for these things to be addressed by an
> eclass vrs everybodys the ebuilds themselfs.
Having both installed simultaneously is a very messy business already,
as they both use /home/httpd, and contain binaries with identical names.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] apache.eclass proposed

[Brad Laue]

Robin H.Johnson wrote:
> I believe that would be a better solution than looking for the
> DocumentRoot they have set. As an example, I run a couple of webservers
> at work. Their DocumentRoot is /var/www, which is a read-only NFS mount.

The means by which the DocumentRoot is found is actually pretty elegant
and the functionality of that can easily be placed in an eclass. I'd
consider this a big plus in terms of usability. As you're pointing out,
/var/www is the FHS compliant place to put the documentroot anyway, so
I'm not sure why we're being like RedHat in this respect.

I don't think we should remove this. If there are ebuilds that don't
comply with this method of finding out where the documentroot is, they
can be fixed all the more easily using an eclass.

> One further thing with the DocumentRoot issue. Say I have two systems
> that share binary packages, but they have different DocumentRoot
> settings. I create the binary tbz2 on the first system, and it packages
> everything up with the first path, say /home/httpd/htdocs. Then I want
> to also install on the second system, which has a DocumentRoot of
> /var/www. The files would still be installed to /home/httpd/htdocs,
> defeating the purpose of your check for the DocumentRoot setting.

Is pkg_preinst observed when emerging a .tbz2 package? This would be
another thing to change about the ebuilds in question.

At the very least, why don't we make the httpd user's home directory
/var/www? Alas, if we did so we would still require detection routines
for currently installed systems.

Brad

-- 
// -- http://www.BRAD-X.com/ -- //


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache.eclass proposed

[Donny Davies]

Ned Ludd wrote:
>The means by which the DocumentRoot is found is actually pretty elegant
>and the functionality of that can easily be placed in an eclass. I'd
>consider this a big plus in terms of usability. As you're pointing out,
>/var/www is the FHS compliant place to put the documentroot anyway, so
>I'm not sure why we're being like RedHat in this respect.

  I would strongly advise you to get your facts straight before
rolling through here muttering something like that.  This is not
correct.  I'm afraid you need to do some remedial reading on the
situation.

  You may want to visit http://www.pathname.com/fhs/ where you
can learn that there *IS* no standard for this.  And as such,
the location in which to install Apache and other web-related
files, is simply nothing more the opinion of the person you're 
currently talking to.  The current FHS version doesnt address
this area.  I havent looked at any of the work in progress for
FHS 2.3 by the way; perhaps there's new developments there?

  If you want even more standards, then please open your
config.layout file, distributed with the Apache source code,
and well, take your pick from several more "standards".

>At the very least, why don't we make the httpd user's home directory
>/var/www? Alas, if we did so we would still require detection routines
>for currently installed systems.

  There are other reasons to use this location, but none of them
to do with FHS.  :-)

  As for the apache2 USE flag; I made it so that the mod_php
ebuild didnt have to *guess* at which API to build the DSO
for.  I've talked with Robin about this, and we'd both very
much like to see it "go away".  It's nasty.


Robin H.Johnson wrote:
>Having both installed simultaneously is a very messy business already,
>as they both use /home/httpd, and contain binaries with identical names.

  They are configured to serve from the same DocumentRoot.  I
didnt want to introduce *another* docroot.  They'll overwrite
some icons from the other's install.  I assume those who
really, really want those default ASF icons from the other
version, can figure out howto get them from the tarball.
Same for the default introduction pages.  Is this a big
deal?  What binaries are you talking about?  I took
pains to SLOT=2 Apache2, Im not aware of any binaries
getting overwritten.

  As for the eclass, it's obviously a natural progression. 
I have not attempted to create one yet because I dont
really have a great idea for what functions it should
provide.  The very basic ones proposed were simply not
enough to convince me to add this yet.  If they were
I would have added one months ago.  What other functions
would be desired from an web-related eclass?  I'm not
*completely* and outright opposed to the stuff proposed,
Im just saying it's weak, and well, it certainly isnt
a sic "way to totally and easily manage the whole
Apache config" as somebody else mentioned.   Far from
it.

  Further, Im not of the opinion that having a "bonifide"
location in which to install these files on a Gentoo
system (/home/httpd/{htdocs,cgi-bin} is a BAD idea,
and having them just the way they are now at least
provides this.

                Donny.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache.eclass proposed

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 6734 bytes --]

On Mon, Jun 09, 2003 at 11:02:05PM -0400, Donny Davies wrote:
> Ned Ludd wrote:
> >The means by which the DocumentRoot is found is actually pretty elegant
> >and the functionality of that can easily be placed in an eclass. I'd
> >consider this a big plus in terms of usability. As you're pointing out,
> >/var/www is the FHS compliant place to put the documentroot anyway, so
> >I'm not sure why we're being like RedHat in this respect.
>  I would strongly advise you to get your facts straight before
> rolling through here muttering something like that.  This is not
> correct.  I'm afraid you need to do some remedial reading on the
> situation.
I agree with Donny here. There is no standard place to put the
DocumentRoot. I have always used /var/www for a variety of reasons.
Amongst them, is that /home is in many larger setups, an NFS mount, and
I don't particuallar want to always have it mounted. (I am presently
looking at auto-mounting just the current users home directories install
of all of /home).

My personal setups for Apache do away with a single DocumentRoot, as I
usually have a number of VirtualHosts on each machine. 

I do:
DocumentRoot /var/www/(domain)/(host)/
such that:
www.orbis-terrarum.net
comes from
/var/www/orbis-terrarum.net/www/

>  You may want to visit http://www.pathname.com/fhs/ where you
> can learn that there *IS* no standard for this.  And as such,
> the location in which to install Apache and other web-related
> files, is simply nothing more the opinion of the person you're 
> currently talking to.  The current FHS version doesnt address
> this area.  I havent looked at any of the work in progress for
> FHS 2.3 by the way; perhaps there's new developments there?
There is nothing proposed for this in FHS2.3 AFAIK, or can find in the
FHS BugZilla.

>  If you want even more standards, then please open your
> config.layout file, distributed with the Apache source code,
> and well, take your pick from several more "standards".
And be aware of the 'Gentoo' layout in it that we use for Apache2.
For Apache1, the ebuild specifies locations directly to override where
they are installed instead of the clean layout route that is used in
Apache2.

>  As for the apache2 USE flag; I made it so that the mod_php
> ebuild didnt have to *guess* at which API to build the DSO
> for.  I've talked with Robin about this, and we'd both very
> much like to see it "go away".  It's nasty.
To revisit that discussion, I've actually had two users come to me
with another, better reason to have both installed at the same time:
"Being able to develop a web application that has to run in BOTH
environments, with only a single machine to work on."
"Using a single machine, running Apache2 for some custom module they
have, as well as having a really minimal Apache1 running to serve
tarballs without the overhead added by the Apache2 stuff they use."

> Robin H.Johnson wrote:
> >Having both installed simultaneously is a very messy business already,
> >as they both use /home/httpd, and contain binaries with identical names.
>  They are configured to serve from the same DocumentRoot.  I
> didnt want to introduce *another* docroot.  They'll overwrite
> some icons from the other's install.  I assume those who
> really, really want those default ASF icons from the other
> version, can figure out howto get them from the tarball.
> Same for the default introduction pages.  Is this a big
> deal?  What binaries are you talking about?  I took
> pains to SLOT=2 Apache2, Im not aware of any binaries
> getting overwritten.
My apologies. Earlier on in the lifespan of Apache2 in Gentoo, more
things were overwritten, but it seems practically all of that is cleared
up now.
There are exactly two files outside of icons and htdocs that are
overwritten:
/home/httpd/cgi-bin/printenv
/home/httpd/cgi-bin/test-cgi
Seeing as they are identical in both Apache1 and Apache2, I don't see
any need for concern with them.

I also made a further comparision on icons and htdocs via md5sums.
Icons between the two are identical, and the old difference is that
Apache2 has a bunch of 'powered by apache2' logos as additional items.
The contents of htdocs have changed significently however, with no
common files between the two remaining the same.

> As for the eclass, it's obviously a natural progression. 
> I have not attempted to create one yet because I dont
> really have a great idea for what functions it should
> provide.  The very basic ones proposed were simply not
> enough to convince me to add this yet.  If they were
> I would have added one months ago.  What other functions
> would be desired from an web-related eclass?  I'm not
> *completely* and outright opposed to the stuff proposed,
> Im just saying it's weak, and well, it certainly isnt
> a sic "way to totally and easily manage the whole
> Apache config" as somebody else mentioned.   Far from
> it.
One point for a web applications eclass:
When web servers BEYOND Apache are present, the complexity involved in
finding the 'DocumentRoot' equivilent grows a LOT, and then it does make
sense to belong in an eclass, as somebody adding a web application
doesn't want to have to figure out the details behind how to get the
DocumentRoot from AOLServer for example.

We are a lot closer to this than you may realize.
We do presently have a few web servers:
Apache1/2
publicfile
resin(-ee)
mini_httpd
fnord

There really should be a virtual/webserver that many of these provide,
but you get into issues of what modules can be used to a degree.
There should NOT however, be anything to restricts you to only having a
single webserver installed.

>  Further, Im not of the opinion that having a "bonifide"
> location in which to install these files on a Gentoo
> system (/home/httpd/{htdocs,cgi-bin} is a BAD idea,
> and having them just the way they are now at least
> provides this.
As I originally stated, installing to a fixed location would be fine, as
that would be fine for the great majority of users. How that location is
chosen is arbitary.

For the sake of backwards-compatibility and support more servers easily,
perhaps some form of installing the actual files for each server into
/usr/share/(server)/... and symlinking them into /home/httpd would make
more sense? Note that the files should be explictly symlinked, and NOT
the directories for 'htdocs' and 'cgi-bin'.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] apache.eclass proposed

[Stewart]

Ned Ludd wrote:
> After writing a net-www/ ebuild it seemed apparent to me that we are
> going to need an apache.eclass. A quick find in portage reveals quite a
> few independent ebuilds all needing the basic functionality that could
> be provided by an apache.eclass

Absolutely. I'm presently maintaining a couple net-www ebuilds and found 
it annoying that the default HTDOCS folder was assumed. I'd rather see a 
unified eclass file than a kludge in every ebuild.

Most everything looks great, and I'd love to begin testing this. I've 
got three production and half a dozen test servers at my disposal with 
various combinations of Apache and Squid installed that I'd be able to 
toy with at the moment.

-- 
Stewart Honsberger
http://blackdeath.snerk.org/
"Capitalists, by nature, organize to protect themselves.
-- Geeks, by nature, resist organizaion."


--
gentoo-dev@gentoo.org mailing list