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
