From: David W Noon <dwnoon@ntlworld.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Updating libpng: another libtool cockup?
Date: Mon, 19 Sep 2011 16:49:55 +0100 [thread overview]
Message-ID: <20110919164955.0f8e86ba@karnak.local> (raw)
In-Reply-To: <20110919161002.52493882@rohan.example.com>
[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]
On Mon, 19 Sep 2011 16:10:02 +0200, Alan McKinnon wrote about Re:
[gentoo-user] Re: Updating libpng: another libtool cockup?:
> On Mon, 19 Sep 2011 03:06:30 -0700
> walt <w41ter@gmail.com> wrote:
[snip]
> > I don't skip the --library step any more.
>
> That's odd behaviour, I wonder what caused the difference.
I guess your graph theory is out to lunch today. ... :-)
The problem is portage determining the dependency graph, but ebuilds do
not contain enough information to do this thoroughly. The best
example, at least in my memory, was the libexpat upgrade about 4 years
ago that trashed everybody's system -- many resorted to complete
re-installation.
At the end of that upgrade, there was an instruction to preform a
revdep-rebuild specifically for libexpat.so. Now, this upgrade
coincided with a full upgrade to KDE plus a full upgrade to GNOME, all
on the same day. As a result, the message to do a revdep-rebuild
specifically on libexpat was buried in other bumpf, plus there was other
library breakage out the yin-yang -- an extremely large yin-yang. It
was a sysadmin's perfect storm.
Doing a simple revdep-rebuild, with no library constraint, caused
ebuild breakage by the mile. This was because the subroutines in
libexpat are used inside ebuild processing by documentation utilities
such as ghostscript, xsltproc, etc.
OTOH, if one did a specific revdep-rebuild on libexpat, all of those
documentation utilities would be rebuilt before the main
revdep-rebuild. After that, the ebuilds all went smoothly.
Unfortunately, Portage does not have enough information to infer these
deep dependencies. This means it cannot schedule the more fundamental
revdep-rebuild ahead of those that depend upon it. We have to do that
by hand.
I hope this has explained why we should take messages about running
"revdep-rebuild --library libXXX" seriously.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2011-09-19 15:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-18 20:10 [gentoo-user] Updating libpng: another libtool cockup? walt
2011-09-18 20:48 ` Michael Mol
2011-09-18 20:57 ` Thanasis
2011-09-18 21:54 ` Mick
2011-09-18 21:58 ` Allan Gottlieb
2011-09-18 23:39 ` Alan McKinnon
2011-09-19 10:06 ` [gentoo-user] " walt
2011-09-19 14:10 ` Alan McKinnon
2011-09-19 14:20 ` Allan Gottlieb
2011-09-19 14:34 ` Michael Schreckenbauer
2011-09-19 14:58 ` [gentoo-user] Re: Updating libpng: another lib tool cockup? Allan Gottlieb
2011-09-19 15:19 ` Michael Schreckenbauer
2011-09-19 15:28 ` Alan McKinnon
2011-09-19 15:49 ` Michael Schreckenbauer
2011-09-19 15:49 ` Paul Hartman
2011-09-19 17:57 ` Allan Gottlieb
2011-09-19 18:19 ` Paul Hartman
2011-09-19 20:08 ` Allan Gottlieb
2011-09-20 10:38 ` Neil Bothwick
2011-09-20 12:57 ` Allan Gottlieb
2011-09-19 16:30 ` covici
2011-09-19 14:36 ` [gentoo-user] Re: Updating libpng: another libtool cockup? Michael Mol
2011-09-19 20:33 ` Mark Knecht
2011-09-19 20:41 ` Michael Mol
2011-09-19 20:52 ` Mark Knecht
2011-09-19 21:10 ` Michael Schreckenbauer
2011-09-19 21:28 ` Mark Knecht
2011-09-19 15:07 ` walt
2011-09-19 15:49 ` David W Noon [this message]
2011-09-19 20:54 ` Peter Humphrey
2011-09-19 22:29 ` covici
2011-09-20 10:41 ` Neil Bothwick
2011-09-19 14:06 ` [gentoo-user] " Allan Gottlieb
2011-09-19 21:04 ` [gentoo-user] " Nikos Chantziaras
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=20110919164955.0f8e86ba@karnak.local \
--to=dwnoon@ntlworld.com \
--cc=gentoo-user@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