Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Stuart Longland <redhatter@g.o>
Subject: Thoughts about broken package handling
Date: Sun, 26 Jun 2011 12:59:05 +1000
Hi all,

I've been busy for the past month or two, busy updating some of my
systems.  In particular, the Yeeloong I have, hasn't seen attention in a
very long time.  Soon as I update one part however, I find some swath of
packages break because of a soname change, anything Python-related stops
working because of a move from Python 2.6 to 2.7, or Perl gets updated.

Currently we have three packages that handle this separately:
- revdep-rebuild (handles packages broken by soname changes, etc)
- python-updater (handles Python module rebuilds after upgrading Python)
- perl-cleaner (handles Perl module rebuilds after upgrading Perl)

My bugbear at the moment, is often a package is broken for more than one
reason in my situation, and I find myself having to manhandle the
package lists generated by the above three, building each package
one-by-one, until I manage to rebuild them all.

Or sometimes a package being rebuilt by revdep-rebuild fails because of
a Python module, I'll manually merge that module, then play another
round of Russian Roulette to see which package gets shot down next.

Issues are complicated further when revdep-rebuild or whatever tool,
passes the list to Portage, and it fails to calculate dependencies... I
just had one before where revdep-rebuild failed because there were no
ebuilds to satisfy:


I've worked around this by picking up the list generated by
revdep-rebuild (in /var/cache/... ), and using a bash while read loop to
pass each package individually to emerge for building.

How well is this cleanup trio working?  It works, but I think it could

The thing I see is that all three are fixing essentially the same
problem: package breakage due to a change in the dependencies.  I think
there is scope for a single package, or better yet, Portage extension,
that handles all three cases.


Tool will be written in separate modules to handle:
- ELF soname change breakage
- Python module updates
- Perl module updates
- other checks that can cause broken packages...

Each check is run in order, generating a list of packages that should be

Having generated this list, it is then evaluated to sort the candidate
packages into a suitable order for rebuilding.

This is then passed to the package manager... three modes for rebuilds:
- All-in-one-hit rebuild: What the tools presently do now.
- One-by-one rebuild: For each package in the list, build each one
individually... useful if Portage coughs up an error otherwise
- Dump the list: allows people to handle it with their own tools

I might see if I can rough something up, but that's what I'm thinking
of.  It has been an irritation for me for quite some time.

Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'             :.'

I haven't lost my mind...'s backed up on a tape somewhere.

Re: Thoughts about broken package handling
-- Stefan Behte
Re: Thoughts about broken package handling
-- Philip Webb
Re: Thoughts about broken package handling
-- Thomas Sachau
Re: Thoughts about broken package handling
-- Kent Fredric
Re: Thoughts about broken package handling
-- Benedikt Böhm
Re: Thoughts about broken package handling
-- Duncan
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
SHA256 and indention in metadata.xml
Next by thread:
Re: Thoughts about broken package handling
Previous by date:
Re: Re: RFC: split up media-sound/ category
Next by date:
Re: Re: RFC: split up media-sound/ category

Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.