FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-30-2009, 09:11 AM
Robert Bradbury
 
Default Why do packages which will not build remain in the distribution list?

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
 
Old 12-30-2009, 09:18 AM
Petteri Räty
 
Default Why do packages which will not build remain in the distribution list?

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
 
Old 12-30-2009, 10:58 AM
Richard Freeman
 
Default Why do packages which will not build remain in the distribution list?

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
 
Old 12-30-2009, 11:10 AM
Alex Legler
 
Default Why do packages which will not build remain in the distribution list?

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
 

Thread Tools




All times are GMT. The time now is 01:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org