I've noticed a lot of broken packages this week -- things like gentoo-sources(kernel), and the gnome & qt libraries.

Working through the errors by hand, I can usually figure out what dependency was missing: it's almost always a high-use, core library that the box is missing because it's a fresh install. But this leads me to wonder: what sort of error checking could be built into portage to prevent this?

In my dreams, there's a high-powered array of machines dedicated to from-scratch installs, all running with the fastest processors and installing into RAM, so we never have to worry about the delays of writing to a drive.

In my dreams, this barrier stands between the maintaners and portage itself, only allowing updates to the live system when the package installs cleanly without human intervention. This has nothing to do with the stability or development state of the code. Only that it will build without problems.

A step below that, package maintainers keep a box in common or partitions on their own boxes, and run from- scratch installs on that, confirming the proper intsallation before making the change public.

A tier below that, somebody writes a script to rsync regularly, and build any changes from scratch. Maybe this could even be a distributed process?

In any of these, the error messages might be machine parseable, so that there could be some attempt at correcting the situation.

Maybe that's closer to the right solution -- make portage a system that can make reasonable guesses about what's missing to cause a merge failure, and to submit bug-reports & possibly patches...

But, on a more serious note, Gentoo is a young distro -- the testing infrastructure is obviously seriously lacking, but give it time and I imagine it will come along.

Another problem is funds. Someone has to pay for all those fast machines with gobs of RAM so Gentoo can test all ebuild scripts across all platforms. This is not an insignificant investment. Selling $5 CDs isn't going to cut it. Actually, Gentoo users, by themselves, probably can't support this level of investment -- it's got to come from corporate sponsorship. *cough*IBM*cough*

Anyway, I agree with all your points -- I think ebuild scripts should be heavily tested on default installations and I think they shouldn't be released to the unwashed masses before they pass a set of regression tests. My suggestion is to take your suggestion and file it as a suggestion on bugs.gentoo.org.

--kurt_________________The problem with political jokes is that they get elected

I've a confession to make -- I tried Debian, and found I couldn't wrap my head around it. It just didn't *feel* right. (Mandrake left me too boxed in, LFS promised to be too much work....) Gentoo is the first distro I've come across that felt intuitive without being candy-coated and surrounded by yellow police tape.

Anyway...

By default, portage is connecting to ftp / http sites to download sources, so it seems like automatically submitting emerge failures might be cheap and easy to implement on top of the existing base.

Ideally, error reports would go to one location. Depending on the resources available, this could be as simple as hitting a package-specific counter URL. That doesn't seem like it would generate much traffic, compared to everyone running "emerge rsync". If we were feeling rich, it might even be worthwhile to include compiler / error output to speed bug tracking.

(And I know *I'd* put the price of a commercial boxed distro toward this kind of functionality.)

It also seems like this would cut the developers' workload, in the long term. Now, instead of having to sift through a half dozen complaints about a package (or its dependants) not building, they might get a single, system-generated bug telling them exactly which package was failing at the root, and exactly which packages were failing as a result.

Issues I see:
-- how to tell that the problem isn't self-inflicted, ie that the user didn't delete something

In any case, I plan to submit a feature suggestion, but first I'd like others to pick over this. The more I think about it, the more this seems like a really good way to make Gentoo shine.