From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NPxCs-0007rb-KJ for garchives@archives.gentoo.org; Wed, 30 Dec 2009 11:59:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4FC4DE0683; Wed, 30 Dec 2009 11:58:49 +0000 (UTC) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by pigeon.gentoo.org (Postfix) with ESMTP id 355AAE0683 for ; Wed, 30 Dec 2009 11:58:49 +0000 (UTC) Received: from gw.thefreemanclan.net ([unknown] [96.245.54.62]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KVG006UWRY0D5ND@vms173001.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Wed, 30 Dec 2009 05:58:49 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gw.thefreemanclan.net (Postfix) with ESMTPS id 80FC9175A493 for ; Wed, 30 Dec 2009 06:58:48 -0500 (EST) Message-id: <4B3B4078.4000504@gentoo.org> Date: Wed, 30 Dec 2009 06:58:48 -0500 From: Richard Freeman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091229 Thunderbird/3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Why do packages which will not build remain in the distribution list? References: <4B3B290F.8070909@gentoo.org> In-reply-to: <4B3B290F.8070909@gentoo.org> Content-type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 5067a524-ca2f-41a8-ac19-df1f343041ef X-Archives-Hash: 85fb751cd4dce9eb29ae460ff56ce8a1 On 12/30/2009 05:18 AM, Petteri R=C3=A4ty 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 th= e > 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=20 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=20 command on, without a -1 on the command line. So, if you type=20 emerge xterm, then xterm is in your world set. A package is removed=20 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=20 install are not added to world, unless you later manually emerge them=20 without a -1 on the command line. The idea is that anything you explicitly ask for is something that=20 portage will try to keep around for you, and anything you don't=20 explicitly ask for is something that portage will try to get rid of if=20 it isn't needed later. So, those ruby packages ended up in world because you emerged them. Any=20 new version that goes stable/testing on those packages will consequently=20 get pulled in by an emerge -u world. The real issue (as was pointed out) is that packages shouldn't even be=20 marked for testing (let alone stable) if they don't actually build, or=20 if they have serious problems. They should be masked, so that only=20 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=20 sometimes you can run into build issues due to a need to run=20 revdep-rebuild, or lafilefixer, or to rebuild some library. I had an=20 x86 chroot that absolutely refused to build imagemagick until I just=20 reinstalled the whole thing from stage3 - probably some obscure=20 library/compiler problem. So a build error might not reflect a problem=20 with the package you're trying to build. Obviously we still try to=20 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=20 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=20 can poke maintainers or step in as appropriate. Note that I haven't reviewed the packages/bugs that are being discussed=20 here, so none of this is targeted at anybody in particular. I'm just=20 pointing out how things like this are supposed to work in general. Rich