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

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

[Robert Bradbury]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

For the last week or so, there have been packages in the "world"
distribution list which previously installed fine which currently do not,
these include ruby-gdkpixbuf2, ruby-pango, ruby-gtk2, ruby-gnomecanvas2,
ruby-gnome2 and ruby-libglade2 (this is on an x86 system).  My reading of
the bug reports suggest that this is a problem with the ruby/gentoo config
scripts.  If so, ok fine, then pull them from the "world" distribution until
such scripts/ebuilds/patches are available.  Please do not leave them in the
world distribution list when they are known to be defective.  It appears
that there may be some oversight/direction lacking with respect to what
makes up the QA with respect to distributed (e.g. "approved") packages which
have known problems.

For people who attempt to update their systems on a nightly basis and
provide feedback to the Gentoo developers, this can be an annoying situation
(it may require the expansion/contraction of scripts which enable/disable
nightly builds).

I understand if there is a problem with the upstream source which may take
months to fix for the bug reports to percolate up and solutions to percolate
down, but in the mean time end users should not be subjected to packages
known to be problematic (and thus the packages should be pulled from the
world distribution list).

Robert

[-- Attachment #2: Type: text/html, Size: 1454 bytes --]

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

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

On 12/30/2009 12:11 PM, Robert Bradbury wrote:
> For the last week or so, there have been packages in the "world"
> distribution list which previously installed fine which currently do
> not, these include ruby-gdkpixbuf2, ruby-pango, ruby-gtk2,
> ruby-gnomecanvas2, ruby-gnome2 and ruby-libglade2 (this is on an x86
> system).  My reading of the bug reports suggest that this is a problem
> with the ruby/gentoo config scripts.  If so, ok fine, then pull them
> from the "world" distribution until such scripts/ebuilds/patches are
> available.  Please do not leave them in the world distribution list when
> they are known to be defective.  It appears that there may be some
> oversight/direction lacking with respect to what makes up the QA with
> respect to distributed (e.g. "approved") packages which have known problems.
> 

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 make sure nothing in those files pulls in the packages that you
have issues with and they are no longer part of your world set. What
really should happen is that bug reports are filed on things that don't
build and they are package.masked if they can't be fixed in a reasonable
time frame.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

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

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Wed, 30 Dec 2009 06:58:48 -0500, Richard Freeman <rich0@gentoo.org>
wrote:

> [...]
> So a build error might not reflect a
> problem with the package you're trying to build. 

This is the case here.
Some packages install broken pkg-config files (missing a Name: field)
which will cause pkg-config --list-all to fail when encountering such
a package. That in turn also makes the Ruby pkg-config library fail
which is used in the configure step.

We already have filed some bugs against these broken packages. Now we
have to wait until all are fixed, or find a way to make pkg-config more
resistant to such errors -- both are outside of the Ruby team's realm.

Alex

-- 
Alex Legler | Gentoo Security / Ruby
a3li@gentoo.org | a3li@jabber.ccc.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]