From: Richard Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Why do packages which will not build remain in the distribution list?
Date: Wed, 30 Dec 2009 06:58:48 -0500 [thread overview]
Message-ID: <4B3B4078.4000504@gentoo.org> (raw)
In-Reply-To: <4B3B290F.8070909@gentoo.org>
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
next prev parent reply other threads:[~2009-12-30 11:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-30 10:11 [gentoo-dev] Why do packages which will not build remain in the distribution list? Robert Bradbury
2009-12-30 10:18 ` Petteri Räty
2009-12-30 11:58 ` Richard Freeman [this message]
2009-12-30 12:10 ` Alex Legler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B3B4078.4000504@gentoo.org \
--to=rich0@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox