Yes, I was one of the many people who emerged the new apache ebuild
without paying sufficient attention to the mailing list post announcing
the dramatic changes.  *Shrug*  It took me a day or so to get things
fixed, but that was my own fault, and I have no complaints about the
new config.  

On the other hand, I do have a concern about the frequent posts I've
seen from our apache devs along the lines of "They [who had broken their
systems] obviousely didn't care, [sic] that ~arch is for testing. That of
course implies, that not everything will succeed as expected."
[http://trapni-akane.org/blog/index.php/trapni/2005/03/12/apache_and_the_enduser]
The serious breakage for people occurred because the apache devs
released into ~arch the new apache ebuild before a number of rather
important apache-module ebuilds had been rewritten to use the new
apache config.  Now, I think we've all done things like that (forgotten
a dependency, or something that uses the current package as a
dependency, or missed an obscure USE flag) by accident, and that's why
we have an ~arch tree.  The ~arch tree, at least in my understanding,
is for testing ebuilds, and it's not surprising that sometimes the
e-build has an error in it.  However, I don't believe that ~arch should
be used for ebuilds that one _knows_ have broken functionality.  For
such cases we have package.mask.

So, what should one do about a package that, in and of itself, is fully
functional, but related packages have not yet been updated and package
maintainers cannot be urged to move faster to fix the packages?  Well, nagging
on bugs is usually the first step, followed by nagging on -dev so that
people know that there is a problem.  If that doesn't work, the 
traditional method is to patch the related ebuilds oneself, add the
patched ebuilds to package.mask in a nice big block along w/ the
principal package, and start asking people to test.  That way, once it
appears that the bugs are reasonably worked out the whole block can be
unmasked at once, minimizing pain for our users who "can't read".
Moreover, once this step is done it is perfectly reasonable to post a
bug and a message to -dev saying "New foo system seems to be working,
and we plan to unmask all at once in 30 days unless any maintainers of
these packages [provide list] explicitly tells us not to do so."

Might this approach take a long time and involve a lot of frustration?
Yes, of course it might.  I understand that in this case the non-masked
apache ebuild was lagging further and further behind upstream, and that
the frustration for the apache devs was particularly acute.  However, I
think it's safe to say that our users would rather have older versions
with everything working, and the easy ability to use package.unmask if
the latest-and-greatest is needed, than to have the latest-and-greatest
in a semi-broken state.

My thoughts, please feel free to disagree with me.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76