Grant Goodyear wrote:
> 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.

In defense of the Apache team, and myself as I am leading the unmasking
of Apache and it's modules....

I believe the specific situation you are referring to is mod_php. We did
patch it and have it hard masked, and wanted the php herd's stamp of
approval before we unmasked it. All of us that are working on this are
rather new developers (I myself have only been a dev since December),
and didn't want to break someone else's package, especially one as
complex as PHP. So we left it hard-masked while unmasking ours, and
referenced users to the already open bug about mod_php and also pointed
users at the hard-masked revision of mod_php that worked for us. I agree
it could have been handled better, but what we did seemed like enough at
the time. The packages are in ~arch, and we never intended them to go to
stable without all other expected packages there as well.

Some have suggested that we move backwards into hard-mask. I disagree 
with this. When we moved from hard-mask to ~arch, we did so to get a 
wider testing audience. We have run into a few glitches here and there, 
but that is the point of ~arch, to work all the glitches out before 
moving to stable. The major breakage that most users came across was the 
unexpected non-working of mod_php. And now mod_php revision that works 
with the new apache revision is no longer in hard-mask. Moving back to 
hard-mask at this point in time would only cause more headaches then 
pushing forward to get everything working together. Arguments for either 
side are welcome however.


-- 
Michael Stewart                                     vericgar@gentoo.org
Gentoo Developer                        http://dev.gentoo.org/~vericgar

GnuPG Key ID 0x08614788 available on http://pgp.mit.edu
--