Re: [gentoo-dev] Why do packages which will not build remain in the distribution list?

[Richard Freeman]

On 12/30/2009 05:18 AM, Petteri Räty wrote:
> You need to understand what the world set means. The world set is the
> packages in /var/lib/portage/world and the sets from
> /var/lib/portage/world_sets . From this follows that we can't change the
> content of the world set as it's a user specific configuration issue.

Just to clarify a little (the above is completely accurate, but it might 
not be obvious how portage works just from reading this):

The world set is a list of every package that you've executed an emerge 
<package> command on, without a -1 on the command line.  So, if you type 
emerge xterm, then xterm is in your world set.  A package is removed 
from world if you uninstall it, or if you edit that file manually.

Packages that are installed because they are needed by packages that you 
install are not added to world, unless you later manually emerge them 
without a -1 on the command line.

The idea is that anything you explicitly ask for is something that 
portage will try to keep around for you, and anything you don't 
explicitly ask for is something that portage will try to get rid of if 
it isn't needed later.

So, those ruby packages ended up in world because you emerged them.  Any 
new version that goes stable/testing on those packages will consequently 
get pulled in by an emerge -u world.

The real issue (as was pointed out) is that packages shouldn't even be 
marked for testing (let alone stable) if they don't actually build, or 
if they have serious problems.  They should be masked, so that only 
those interested in developing/debugging the package get hit with it.

I don't want to comment on the packages you listed in particular, but 
sometimes you can run into build issues due to a need to run 
revdep-rebuild, or lafilefixer, or to rebuild some library.  I had an 
x86 chroot that absolutely refused to build imagemagick until I just 
reinstalled the whole thing from stage3 - probably some obscure 
library/compiler problem.  So a build error might not reflect a problem 
with the package you're trying to build.  Obviously we still try to 
avoid these kinds of issues and warn users when they are likely to happen.

I'd continue to follow the bug, and if it seems like something like this 
isn't being resolved expediently feel free to contact the QA team:
http://www.gentoo.org/proj/en/qa/

The QA team ensures that Gentoo quality policies are being followed and 
can poke maintainers or step in as appropriate.

Note that I haven't reviewed the packages/bugs that are being discussed 
here, so none of this is targeted at anybody in particular.  I'm just 
pointing out how things like this are supposed to work in general.

Rich