Bugzilla Bug 41124

dev-perl/XML-Parser not in dependencies for gnome-vfs-2.4.2-r1

Reproducible: Always
Steps to Reproduce:
1.unmerge dev/perl/XML-Parser
2.emerge gnome-vfs-2.4.2-r1
3.

Actual Results:  
ebuild stops while configure

it deps on >=intltool-0.29 which deps on XML-Parser.

emerging gnome-vfs-2.4.2-r1:
*******************************************************************
checking for perl... /usr/bin/perl
configure: error: XML::Parser perl module is required for intltool

!!! ERROR: gnome-base/gnome-vfs-2.4.2-r1 failed.
!!! Function econf, Line 365, Exitcode 1
!!! econf failed
*******************************************************************

Running the test from gnome-vfs ./configure script:
*******************************************************************
# perl -e "require XML::Parser" 2>&1 | tr ' ' '\n'
Can't
locate
XML/Parser.pm
in
@INC
(@INC
contains:
/etc/perl
/usr/lib/perl5/site_perl/5.8.2/i686-linux
/usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.0/i686-linux
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.6.1
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.2/i686-linux
/usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.0/i686-linux
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.2/i686-linux
/usr/lib/perl5/5.8.2
/usr/local/lib/site_perl
/usr/lib/perl5/site_perl/5.8.0/i686-linux
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.6.1
.)
at
-e
line
1.
*******************************************************************

Location of XML-Parser:
*******************************************************************
# qpkg -l XML-Parser | grep Parser.pm
/usr/lib/perl5/site_perl/5.6.1/i686-linux/XML/Parser.pm
/usr/lib/perl5/site_perl/5.6.1/i686-linux/XML/Parser.pm
*******************************************************************

Seems like the problem is that
/usr/lib/perl5/site_perl/5.6.1/i686-linux
is missing from the @INC-thingy.
I know nothing about perl, so I don't know how to trace
the bug further (who has forgotten to include the directory; perl? XML-Parser?)


Trying to re-emerge XML-Parser...
...and now it works!
Seems like it installed itself into a new location:
*******************************************************************
# qpkg -l XML-Parser | grep Parser.pm
/usr/lib/perl5/site_perl/5.6.1/i686-linux/XML/Parser.pm
/usr/lib/perl5/vendor_perl/5.8.2/i686-linux/XML/Parser.pm
*******************************************************************

Conclusion:
Something perl needs to be fixed.

perl problem needs explanation.

The problem is that the warning, issued at the end of all installs of the
perl-5.8 series, and discussed to no end on the mailing lists a year or so ago
now, was not heeded. When upgrading from a major point release of perl, modules
and executable code compiled against the 5.6.X version of perl must be
re-installed. The location of XML-Parser, in this case, is in a perl 5.6.1
directory which is not part of the user's @INC anymore. This is not a gentoo
perl issue.

Timo - for what it's worth, there is a script in <PORTAGE>/dev-lang/perl/files/
called libperl_rebuilder which does a decent attempt at helping out. It isn't
perfect, but what it does is to essentially look for any perl related ebuilds
you have installed (modules, etc) and attempt to re-emerge them. Hope this
helps!]

-Mike

Sorry for all the posts, its the work of coffee in my system this morning.

Timo/foser - the problem with XML::Parser is that it is compiled as xs code, i.e. against libperl and the libxml libraries to produce a binary module that is usable by perl. When upgrading from 5.6.X to 5.8 (and if you're playing with the beta releases, within some of the 5.8.x tree as well) the API used by perl to interface between external libraries and the perl intrepeter has changed. The rebuilder script I mentioned rebuilds any perl modules and perl dependant items that you have emerged in the past to overcome this change. It is at best a hack (I can say that as I wrote at least the first incarcation of it) and may be overkill in this case. Re-emerging the XML::Parser and related modules will solve your problem in the short term, but the long term problem is that any module you installed under 5.6.1 that isn't *pure* perl but that instead links to something external will fail until rebuilt. This is actually covered in the perl release notes and easily verified. I hope this helps,

-Mike

*** Bug 42579 has been marked as a duplicate of this bug. ***

ok closing again after the conclusive explanation by mcummings (thnx).

This is not our problem.

*** Bug 45433 has been marked as a duplicate of this bug. ***

*** Bug 48387 has been marked as a duplicate of this bug. ***

*** Bug 49869 has been marked as a duplicate of this bug. ***

*** Bug 50944 has been marked as a duplicate of this bug. ***

*** Bug 52668 has been marked as a duplicate of this bug. ***

*** Bug 54863 has been marked as a duplicate of this bug. ***

*** Bug 65754 has been marked as a duplicate of this bug. ***

*** Bug 71125 has been marked as a duplicate of this bug. ***

*** Bug 54195 has been marked as a duplicate of this bug. ***

*** Bug 71081 has been marked as a duplicate of this bug. ***

*** Bug 71222 has been marked as a duplicate of this bug. ***

*** Bug 71329 has been marked as a duplicate of this bug. ***

*** Bug 72256 has been marked as a duplicate of this bug. ***

*** Bug 72683 has been marked as a duplicate of this bug. ***

*** Bug 72743 has been marked as a duplicate of this bug. ***

The package required to be emerged is 
dev-perl/XML-Parser  and not XML::Parser.

emerge XML-Parser

*** Bug 72793 has been marked as a duplicate of this bug. ***

*** Bug 73005 has been marked as a duplicate of this bug. ***

*** Bug 73577 has been marked as a duplicate of this bug. ***

*** Bug 73690 has been marked as a duplicate of this bug. ***

*** Bug 73773 has been marked as a duplicate of this bug. ***

*** Bug 73776 has been marked as a duplicate of this bug. ***

*** Bug 73789 has been marked as a duplicate of this bug. ***

*** Bug 73892 has been marked as a duplicate of this bug. ***

due to this amount of bug-reports maybe we should add a XML-Parser dependency
directly?

The packages already dep on xml-parser via intltool. The problem is  xml-parser
_needs_ to be rebuild after a perl update, but there is no way to tell that to
portage. Portage sees the xml-parser package as already being installed and
moves on to the next dep. Adding xml-parser as a direct dep would have no
effect towards that.

Ok, but I've never had perl 5.6 on this system, so I'm not sure why it would
have caused a problem.

*** Bug 74143 has been marked as a duplicate of this bug. ***

*** Bug 74919 has been marked as a duplicate of this bug. ***

*** Bug 75226 has been marked as a duplicate of this bug. ***

*** Bug 75688 has been marked as a duplicate of this bug. ***

*** Bug 75915 has been marked as a duplicate of this bug. ***

*** Bug 76080 has been marked as a duplicate of this bug. ***

*** Bug 80013 has been marked as a duplicate of this bug. ***

*** Bug 80237 has been marked as a duplicate of this bug. ***

*** Bug 82156 has been marked as a duplicate of this bug. ***

*** Bug 82213 has been marked as a duplicate of this bug. ***

I wonder how feasable it would be to incorporate interoperability between
either portage and CPAN or each ebuild working with CPAN. I'm new to gentoo,
but CPAN would seem ideal. Although I do remember cpan being a kinda nasty last
time I used it with slackware 10

*** Bug 82586 has been marked as a duplicate of this bug. ***

*** Bug 82880 has been marked as a duplicate of this bug. ***

*** Bug 88019 has been marked as a duplicate of this bug. ***

Because people still add themselves to this bug, a note (over a year later).
libperl_rebuilder has been replaced with perl-cleaner, which is by most
accounts cleaner, faster, --oneshot, and guaranteed to make your hair grow
(maybe not the last part).

*** Bug 88260 has been marked as a duplicate of this bug. ***

*** Bug 91488 has been marked as a duplicate of this bug. ***

*** Bug 91822 has been marked as a duplicate of this bug. ***

*** Bug 92462 has been marked as a duplicate of this bug. ***

*** Bug 92547 has been marked as a duplicate of this bug. ***

*** Bug 92562 has been marked as a duplicate of this bug. ***

*** Bug 93705 has been marked as a duplicate of this bug. ***

*** Bug 94526 has been marked as a duplicate of this bug. ***

*** Bug 95992 has been marked as a duplicate of this bug. ***

*** Bug 96247 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
> Timo - for what it's worth, there is a script in 
> <PORTAGE>/dev-lang/perl/files/ called libperl_rebuilder which does a decent 
> attempt at helping out. It isn't perfect, but what it does is to essentially 
> look for any perl related ebuilds you have installed (modules, etc) and
> attempt to re-emerge them. Hope this helps!]

in my 2005.0 system, there is no libperl_rebuilder around, but instead, we shall
use:

/usr/portage/dev-lang/perl/files/perl-cleaner all
what may do a bit too much, but which will hopefully fix the bug the Gentoo way.
I write this repport at once, and hope this script will fix my box before tonight.

Note that XML::Parser is the perl module. In any case, NOBODY should ever try
emerge XML::Parser
thats a very strange mistake.

:: is the module seperator for Perl, not the package descriptor for portage !!!

I dont even think
emerge XML-Parser
should ever be run, since perl-cleaner is alreade THE SCRIPT designed to solve
the actual problem.

BUT: I think that updates of perl should warn and remind to run perl-cleaner to
rebuild everything cleanly.

(In reply to comment #61) 
> BUT: I think that updates of perl should warn and remind to run perl-cleaner 
to 
> rebuild everything cleanly. 
 
Perl does and has for over a year now. The problem is that it gets lost in the 
shuffle of mass updates (no solution available to that). Also, perl-cleaner has 
been broken out from that version and is now emergeable as its own application 
(for future inclusion as an option to revdep_rebuild). 

*** Bug 97653 has been marked as a duplicate of this bug. ***

Okay. What is an end user (such as me who filed the above bug (and apparently
wasted my time)) supposed to do? It appears this has been a problem for a very
long time. Over a year.

(In reply to comment #64)
> Okay. What is an end user (such as me who filed the above bug (and apparently
> wasted my time)) supposed to do? 

Run perl-cleaner...

*** Bug 97840 has been marked as a duplicate of this bug. ***

*** Bug 97901 has been marked as a duplicate of this bug. ***

*** Bug 98016 has been marked as a duplicate of this bug. ***

*** Bug 100768 has been marked as a duplicate of this bug. ***

*** Bug 101016 has been marked as a duplicate of this bug. ***

*** Bug 101316 has been marked as a duplicate of this bug. ***

*** Bug 101385 has been marked as a duplicate of this bug. ***

(In reply to comment #65)
> (In reply to comment #64)
> > Okay. What is an end user (such as me who filed the above bug (and apparently
> > wasted my time)) supposed to do? 
> 
> Run perl-cleaner...

well i did and nothing changed.

*** Bug 103527 has been marked as a duplicate of this bug. ***

*** Bug 103646 has been marked as a duplicate of this bug. ***

*** Bug 103730 has been marked as a duplicate of this bug. ***

*** Bug 107524 has been marked as a duplicate of this bug. ***

(In reply to comment #73) 
> (In reply to comment #65) 
> > (In reply to comment #64) 
> > > Okay. What is an end user (such as me who filed the above bug (and 
apparently 
> > > wasted my time)) supposed to do?  
> >  
> > Run perl-cleaner... 
>  
> well i did and nothing changed. 
 
perl-cleaner modules worked for me but I never saw the message to run this as 
my update went by as part of an emerge -uD world. Perhaps there could be a 
portage enhancement to summarise these types of messages at the end of an 
emerge operation? 

*** Bug 107655 has been marked as a duplicate of this bug. ***

*** Bug 108273 has been marked as a duplicate of this bug. ***

*** Bug 108423 has been marked as a duplicate of this bug. ***

*** Bug 108979 has been marked as a duplicate of this bug. ***

*** Bug 109603 has been marked as a duplicate of this bug. ***

*** Bug 110075 has been marked as a duplicate of this bug. ***

Oh, god. Why don't we just add an explicit dependency on XML-Parser on the said
Gnome packages' ebuild?

That might not be the solution for people doing emerge syncs (see Comment #78,
for example), but it will at least solve issues with *fresh* GRP 2005.1
installations.

Is it *that* hard to put an extra line on the RDEPEND entry in the ebuild?

reply @ #85

Its not that simple.  all of theese people already have XML-Parser installed.
-all- of them.

They also failed to rebuild it when they updated perl, so the module wasn't
found with the current perl install. This is a symptomous bug in the current
setup where an upgrade cannot force rebuilds of all sub-dependancies.    Nothing
will be solved by the added DEPEND.

Does perl have the equivilant of python-updater or revdep-rebuild?  Could it be
run automatically when perl is upgraded?

there is perl-cleaner,  but it cannot be automated.  We don't invoke "emerge"
from inside "emerge" , that would cause a horrid can of worms to come into being.

And really, perl is too big to just PDEPEND on everything ever built and linked
against it...  I'm sure you wouldn't want to open that mess either, right?


you -get- told to run perl-cleaner, but the problem here is once more, that of
people not seeing/Caring about the notes given to them post-emerge.

I can certainly understand not wanting to run emerge from within emerge.

Maybe ebuild needs an "after" function, that schedules some program to be run
after emerge ends?  The, that could run things like revdep-rebuild,
perl-cleaner, python-updater...

Nah, we can just say "run perl-cleaner" and close the bug.

we probably don't want to do that sort of thing from a stability standpoint. 
Ie, since many of the "after" tools could well require human supervision, 
Double installs of python and such items come to mind,  then we don't just want
to be there and force things down their throats.

Anyhow, this is digressing into a portage featurism discussion. 

Solution: run perl-cleaner. dupe bug 41124

*** Bug 110800 has been marked as a duplicate of this bug. ***

*** Bug 110842 has been marked as a duplicate of this bug. ***

*** Bug 111467 has been marked as a duplicate of this bug. ***

*** Bug 111632 has been marked as a duplicate of this bug. ***

*** Bug 116296 has been marked as a duplicate of this bug. ***

Jakub, why did you remove everybody from the CC list?

(In reply to comment #96)
> Jakub, why did you remove everybody from the CC list?

Hint: So that I wouldn't bugspam tens of people everytime someone does not
bother w/ reading ebuild instructions after perl upgrade and/or searching for
dupes? :P

*** Bug 116625 has been marked as a duplicate of this bug. ***

*** Bug 120818 has been marked as a duplicate of this bug. ***

*** Bug 123413 has been marked as a duplicate of this bug. ***

*** Bug 124535 has been marked as a duplicate of this bug. ***

*** Bug 124957 has been marked as a duplicate of this bug. ***

I have a fresh AMD64 install, an intended upgrade.  I copied over my world file
and had ebuild work through it... and guess what I find.

Somehow intltool is built, perl is rebuilt, and XML::Parser is missing.

With the amount of duplicates here, I think forcing a XML::Parser dependency is
a good idea.  The module is specifically searched for in (for example)
gnome-mime-data's ./configure.  As described above, intltool will bring it in,
but if it's already installed but perl's moved around or reinstalled,
XML::Parser dies.

Maybe emerge needs to know more about Perl...

*** Bug 125064 has been marked as a duplicate of this bug. ***

(In reply to comment #103)

Won't help anything at all, it's already installed. You *must* run perl-cleaner
after upgrading perl.

*** Bug 125811 has been marked as a duplicate of this bug. ***

"perl is rebuilt" means recompiled from the same version.

When I was doing the emerges to rebuild my rig for AMD64, Perl would alternate
between 5.8.7 and 5.8.8 many times.  It would downgrade, then upgrade, then
downgrade, then upgrade, and I hadn't touched my /etc/make.conf and
/etc/portage/package.keywords.  Even if I hit perl-cleaner to reinstall
XML::Parser (it was installed before), XML::Parser was missing.

Yes, I know XML::Parser's required for intltool, but we are running into a
situation in which gnome-vfs is *specifically asking* for XML::Parser and not
just intltool.  It's directly asking Perl if it has it, and folks are filing
bugs that are proving that we cannot be 100% sure between the time intltool
gets installed and gnome-vfs is emerged that XML::Parser is going to exist.  We
know we *should* have it, but should and actually have are two different
things.  It's like the hearsay rules in a court of law -- what one person hears
another say has much less weight than what that latter person actually said (we
get it from the horse's mouth, hay breath and all).

Just a 2cents worth - you could always check in unpack with something like:
perl -MXML::Parser -e 'print "$XML::Parser::VERSION"'
to make sure it comes back with a value and stop if not.

*** Bug 127804 has been marked as a duplicate of this bug. ***

*** Bug 128199 has been marked as a duplicate of this bug. ***

*** Bug 128280 has been marked as a duplicate of this bug. ***

*** Bug 128312 has been marked as a duplicate of this bug. ***

What's needed is a way of producing upgrade/update notes at the End of a
mass-update instead of per package.  Very few have the time or forethought to
log an entire emerge, and then check it's output for detailed update notes.

Instead an update log should be produced, and if there is a likelyhood that
something needs to be run, the user should be told...

'!!! IMPORTANT !!! You must read ~/emerge-update.DATESTAMP.txt it contains
vital post-update instructions for keeping your system working.'

Also, why doesn't emerging perl force a 'perl-clean modules' it looks like that
invocation is Supposed to fix exactly this problem, and re-emerging perl IS one
of the steps I tried after manually running cpan and being told it was already
installed...  I'd never have thought to look for an XML-Parser ebuild since
that should upgrade as well.

(In reply to comment #113)
> What's needed is a way of producing upgrade/update notes at the End of a
> mass-update instead of per package.  Very few have the time or forethought to
> log an entire emerge, and then check it's output for detailed update notes.
> 
> Instead an update log should be produced, and if there is a likelyhood that
> something needs to be run, the user should be told...
> 
> '!!! IMPORTANT !!! You must read ~/emerge-update.DATESTAMP.txt it contains
> vital post-update instructions for keeping your system working.'
> 

Unfortunately, that doesn't handle the case in which perl is being recompiled
before gnome-vfs while running an emerge --deep --update --newuse world.

> Also, why doesn't emerging perl force a 'perl-clean modules' it looks like that
> invocation is Supposed to fix exactly this problem, and re-emerging perl IS one
> of the steps I tried after manually running cpan and being told it was already
> installed...  I'd never have thought to look for an XML-Parser ebuild since
> that should upgrade as well.
> 

I'm for that, but I'm also for adding dev-perl/XML-Parser in the dependencies
of gnome-vfs for reasons I stated above (gnome-vfs specifically checks for it,
the dependency-of-a-dependency is similar to heresay in legal circles, and it's
Perl -- assume the user is too lazy to run perl-cleaner, too impatient to run
perl-cleaner, and has the hubris to say the above).

"...assume the user is too lazy to run perl-cleaner, too impatient to run
perl-cleaner..."

Assume the is NOT to lazy to run perl-cleaner, and is NOT to impatient to run
perl-cleaner.  Assume that the user doesn't REALIZE he needs to run
perl-cleaner because the message has scrolled off the screen, or doesn't stand
out in the morass of text that continually spews out of emerge.  Assume that
the message that tells the user to perl-cleaner doesn't tell them what
option(s) they need to run it with.

Assume that's a lot more like the reality of 99.44% of the users who hit this
problem.

*** Bug 128582 has been marked as a duplicate of this bug. ***

*** Bug 128676 has been marked as a duplicate of this bug. ***

(In reply to comment #113)
> What's needed is a way of producing upgrade/update notes at the End of a
> mass-update instead of per package.  Very few have the time or forethought to
> log an entire emerge, and then check it's output for detailed update notes.

At least for my sys-apps/portage-2.1_pre7-r4, the ELOG features described in
/etc/make.conf.example do this quite well. They send me an email for every
warning or error message encountered while running some ebuild. So this feature
is coming, although it might not have reached stable status yet.

*** Bug 129476 has been marked as a duplicate of this bug. ***

*** Bug 129647 has been marked as a duplicate of this bug. ***

*** Bug 81077 has been marked as a duplicate of this bug. ***

*** Bug 131049 has been marked as a duplicate of this bug. ***

*** Bug 131172 has been marked as a duplicate of this bug. ***

*** Bug 131868 has been marked as a duplicate of this bug. ***

I believe that for me a dependency intltools-->XML-Parser would have cured my
"emerge --update world" problem, as it seems as if XML-Parser has not been
installed on my system (at least emerge did not report a previous module and
did not try to remove something after emerging XML-Parser).

True, this dependency does not solve the problem of Perl-Updates, but it may
solve an other problem. 

*** Bug 132233 has been marked as a duplicate of this bug. ***

If you have 5 Packages listed in emerge -pu world, do you bother scrolling up
for each of the compile stuff and look if there *could* be an info?

I once suggested that important messages about ebuilds should be output at the
*end* of *all* ebuilds, along with their package names.

*** Bug 132684 has been marked as a duplicate of this bug. ***

*** Bug 133160 has been marked as a duplicate of this bug. ***

Just to add to the long bug...

XML-Parser was never on my system at all. When I ran "emerge -pv XML-Parser"
(because I saw xkeyboard-config explode when XML::Parser.pm file was missing)
it was going to be a "n" new ebuild.

My system is was a pretty fresh install.

*** Bug 133652 has been marked as a duplicate of this bug. ***

*** Bug 133886 has been marked as a duplicate of this bug. ***

*** Bug 134361 has been marked as a duplicate of this bug. ***

*** Bug 134421 has been marked as a duplicate of this bug. ***

*** Bug 135425 has been marked as a duplicate of this bug. ***

*** Bug 135628 has been marked as a duplicate of this bug. ***

(In reply to comment #136)
> *** Bug 135628 has been marked as a duplicate of this bug. ***
> 
Hi sorry can you provide a summary of steps to solve/workaround the problem?
I've tried to do what I thought was the solution:
1.unmerge dev/perl/XML-Parser
2.emerge gnome-vfs-2.4.2-r1

even run perl-cleaner all
but again when I try to emerge gnome-vfs it fails with same sort of error


checking for XML::Parser... configure: error: XML::Parser perl module is
required for intltool

!!! Please attach the following file when filing a report to bugs.gentoo.org:
!!! /var/tmp/portage/gnome-vfs-2.14.1/work/gnome-vfs-2.14.1/config.log

!!! ERROR: gnome-base/gnome-vfs-2.14.1 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_compile
  ebuild.sh, line 939:   Called src_compile
  ebuild.sh, line 1248:   Called gnome2_src_compile
  gnome2.eclass, line 57:   Called gnome2_src_configure
  gnome2.eclass, line 53:   Called econf '--disable-schemas-install'
'--disable-howl' '--enable-http-neon' '--enable-openssl' '--disable-gnutls'
'--enable-samba' '--enable-ipv6' '--disable-hal' '--disable-avahi'
'--disable-gtk-doc'
  ebuild.sh, line 541:   Called die

!!! econf failed

Ok, it worked now, I needed to update the intltool, otherwise it wouldn't work.
So my steps where,
1.unmerge dev/perl/XML-Parser
2.perl-cleaner all
3.emerge intltool (a new version was available and XMLParser was emerged)
4.emerge gnome-vfs
5.Restart doing what I was doing upgrade to x11 modular.


Thanks,
Pablo
(In reply to comment #137)
> (In reply to comment #136)
> > *** Bug 135628 has been marked as a duplicate of this bug. ***
> > 
> Hi sorry can you provide a summary of steps to solve/workaround the problem?
> I've tried to do what I thought was the solution:
> 1.unmerge dev/perl/XML-Parser
> 2.emerge gnome-vfs-2.4.2-r1
> 
> even run perl-cleaner all
> but again when I try to emerge gnome-vfs it fails with same sort of error
> 
> 
> checking for XML::Parser... configure: error: XML::Parser perl module is
> required for intltool
> 
> !!! Please attach the following file when filing a report to bugs.gentoo.org:
> !!! /var/tmp/portage/gnome-vfs-2.14.1/work/gnome-vfs-2.14.1/config.log
> 
> !!! ERROR: gnome-base/gnome-vfs-2.14.1 failed.
> Call stack:
>   ebuild.sh, line 1539:   Called dyn_compile
>   ebuild.sh, line 939:   Called src_compile
>   ebuild.sh, line 1248:   Called gnome2_src_compile
>   gnome2.eclass, line 57:   Called gnome2_src_configure
>   gnome2.eclass, line 53:   Called econf '--disable-schemas-install'
> '--disable-howl' '--enable-http-neon' '--enable-openssl' '--disable-gnutls'
> '--enable-samba' '--enable-ipv6' '--disable-hal' '--disable-avahi'
> '--disable-gtk-doc'
>   ebuild.sh, line 541:   Called die
> 
> !!! econf failed
> 

*** Bug 136462 has been marked as a duplicate of this bug. ***

*** Bug 136764 has been marked as a duplicate of this bug. ***

*** Bug 138529 has been marked as a duplicate of this bug. ***

*** Bug 139078 has been marked as a duplicate of this bug. ***

*** Bug 139896 has been marked as a duplicate of this bug. ***

*** Bug 141548 has been marked as a duplicate of this bug. ***

*** Bug 141787 has been marked as a duplicate of this bug. ***

*** Bug 142736 has been marked as a duplicate of this bug. ***

*** Bug 142895 has been marked as a duplicate of this bug. ***

*** Bug 143215 has been marked as a duplicate of this bug. ***

*** Bug 145230 has been marked as a duplicate of this bug. ***

*** Bug 145451 has been marked as a duplicate of this bug. ***

*** Bug 145678 has been marked as a duplicate of this bug. ***

*** Bug 146919 has been marked as a duplicate of this bug. ***

*** Bug 148800 has been marked as a duplicate of this bug. ***

*** Bug 149430 has been marked as a duplicate of this bug. ***

*** Bug 150765 has been marked as a duplicate of this bug. ***

*** Bug 151110 has been marked as a duplicate of this bug. ***

I tracked the source of the error and I have noticed that the bug actually
reproduced each time dev-libs/expat is changed (upgraded/downgraded).
It gives :
# perl -e 'use XML::Parser'
Can't load
'/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/XML/Parser/Expat/Expat.so'
for module XML::Parser::Expat: libexpat.so.1: cannot open shared object file:
No such file or directory at /usr/lib/perl5/5.8.8/i686-linux/DynaLoader.pm line
230.
 at /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/XML/Parser.pm line 14
Compilation failed in require at
/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/XML/Parser.pm line 14.
BEGIN failed--compilation aborted at
/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/XML/Parser.pm line 18.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

or something along this line.

The fix I have is to re-emerge dev-perl/XML-Parser after each and every time
dev-libs/expat is changed (upgraded/downgraded) :
# emerge XML-Parser
fixes it.

I believe there should be something put in the dev-libs/expat e-build to do
this.

Kind feedback welcome.

*** Bug 153408 has been marked as a duplicate of this bug. ***

(In addition to comment #157)

This bug is today the second most duplicated, as shown on
- either http://bugs.gentoo.org/duplicates.cgi
- or https://bugs.gentoo.org/duplicates.cgi

Could someone add "XML-Parser expat" to the summary of this bug so that the
relevant developers get to know about it ?

*** Bug 156091 has been marked as a duplicate of this bug. ***

(In reply to comment #159)
> (In addition to comment #157)
> 
> This bug is today the second most duplicated, as shown on
> - either http://bugs.gentoo.org/duplicates.cgi
> - or https://bugs.gentoo.org/duplicates.cgi
> 
> Could someone add "XML-Parser expat" to the summary of this bug so that the
> relevant developers get to know about it ?

Funny thing is that you only need to add XML-Parser as dependancy and it will
SOLVE every new instance. Again waiting almost two years... and it hit me again
today.

*** Bug 158642 has been marked as a duplicate of this bug. ***

*** Bug 162692 has been marked as a duplicate of this bug. ***

*** Bug 168199 has been marked as a duplicate of this bug. ***

gnome-base/libgtop should depend on dev-perl/XML-Parser, otherwise
gnome-base/libgtop fails with an error message

*** Bug 172507 has been marked as a duplicate of this bug. ***

*** Bug 172924 has been marked as a duplicate of this bug. ***

Yay, just hit this again on a fresh install.

What part about 'indirect dependencies are a Bad Thing' do you guys not get?

Come on people. If you consider how much time you are costing yourselves as
well as others, the price of fixing the solution is much smaller than the
problem itself.

It's things like this that give groups bad reps and make people not want to use
an OS / infrastructure.

Either that or are you hanging on to a glimmer of hope that maybe everything
bad will go away in perl6? Good luck.. perl's a good language but I doubt the
capability of its maintainers for coming out with a good product after the 5.x
interpreter series.

Over 2 years, the least you can do is resolve this.

Come on people. If you consider how much time you are costing yourselves as
well as others, the price of fixing the solution is much smaller than the
problem itself.

It's things like this that give groups bad reps and make people not want to use
an OS / infrastructure.

Either that or are you hanging on to a glimmer of hope that maybe everything
bad will go away in perl6? Good luck.. perl's a good language but I doubt the
capability of its maintainers for coming out with a good product after the 5.x
interpreter series.

Over 3 years, the least you can do is resolve this.

*** Bug 173287 has been marked as a duplicate of this bug. ***

*** Bug 180331 has been marked as a duplicate of this bug. ***

*** Bug 180978 has been marked as a duplicate of this bug. ***

*** Bug 182384 has been marked as a duplicate of this bug. ***

*** Bug 183262 has been marked as a duplicate of this bug. ***

*** Bug 183533 has been marked as a duplicate of this bug. ***

Is perl a required dependency of the install CD? Does gentoo 2006 install an
old version of perl?

If not, then to blame the user for fscking up a perl install is probably unfair
in the extreme.

the following sequence of events will probably cause this error to occur...

Install gentoo
emerge xorg
emerge kde-base
emerge mozilla-firefox

(note that, at the time ie just before 2007 came out, I was installing the
latest (afaik) available gentoo).

imho it's pretty crap for a gentoo newbie (like me) to be left wondering what
the hell is going on, over what should be something nice and simple

*** Bug 185589 has been marked as a duplicate of this bug. ***

*** Bug 186388 has been marked as a duplicate of this bug. ***

*** Bug 187063 has been marked as a duplicate of this bug. ***

*** Bug 187870 has been marked as a duplicate of this bug. ***

*** Bug 188359 has been marked as a duplicate of this bug. ***

For all the people getting here via dupes on gnome 2.18 upgrades:

This is because of the expat upgrade.  You need to run:

revdep-rebuild -X

which is in the gentoolkit package.

*** Bug 188372 has been marked as a duplicate of this bug. ***

*** Bug 188392 has been marked as a duplicate of this bug. ***

*** Bug 188396 has been marked as a duplicate of this bug. ***

*** Bug 188419 has been marked as a duplicate of this bug. ***

*** Bug 188427 has been marked as a duplicate of this bug. ***

I just run into this with gnome-base/gnome-vfs-2.18.1 during regular emerge
-avuDN world ... and nearly filed duplicate, because this did not show when
searching for "gnome-vfs" bugs

how can this be marked RESOLVED-INVALID when people keep running into this
again and again? if system is b0rken on regular update (or even on install? -
comment #177) then it is a bug!

*** Bug 188495 has been marked as a duplicate of this bug. ***

*** Bug 188525 has been marked as a duplicate of this bug. ***

*** Bug 188540 has been marked as a duplicate of this bug. ***

*** Bug 188565 has been marked as a duplicate of this bug. ***

*** Bug 188575 has been marked as a duplicate of this bug. ***

*** Bug 188593 has been marked as a duplicate of this bug. ***

(In reply to comment #189)
> how can this be marked RESOLVED-INVALID when people keep running into this
> again and again? if system is b0rken on regular update (or even on install? -
> comment #177) then it is a bug!

Because you didn't read the instructions provided by expat ebuild on upgrade,
as already noted in Comment #183. That's not a bug but a user failure.

Anyway, we are forcing people to recompile this now because of the horrible
flood of duplicate bugs.

17:07:13 <+CIA-15> drac * gentoo-x86/dev-perl/XML-Parser/ (3 files in 2 dirs):
17:07:13 <+CIA-15> Revision bump XML-Parser to avoid problems with expat
upgrade. No changes made to ebuild itself. 

So, even if you have already recompiled this, you'll be forced to do it again
on next emerge --sync, because people simply don't read whatever messages that
are provided, and don't search for duplicate bugs before filing one. Sorry.

I did emerge --system and couldn't notice the message..
Shouldn't these critical messages be appended to the end of the emerge output
via functions in ebuilds like einfo(), ewarn() and eerror()??

(In reply to comment #197)
> I did emerge --system and couldn't notice the message..
> Shouldn't these critical messages be appended to the end of the emerge output
> via functions in ebuilds like einfo(), ewarn() and eerror()??


emerge --system --> emerge --update system

*** Bug 188609 has been marked as a duplicate of this bug. ***

(In reply to comment #197)

Maybe you should read /etc/make.conf.example and use the ELOG features that
have been available for just over 1 1/2 year now.

Yeah, thanks, I already use it. Apparently it doesn't do its job all that well.

Anyway, this is getting rather off topic. I've filed a feature request.
Jakub, feel free to reply at bug #188623

(In reply to comment #201)
> Yeah, thanks, I already use it. Apparently it doesn't do its job all that well.

Yeah, fails to read the messages for you, you have to do it yourself. If you
can't be bothered to do even that, then kindly stop blaming portage for this.

*** Bug 188629 has been marked as a duplicate of this bug. ***

*** Bug 188635 has been marked as a duplicate of this bug. ***

*** Bug 188639 has been marked as a duplicate of this bug. ***

*** Bug 188640 has been marked as a duplicate of this bug. ***

*** Bug 188643 has been marked as a duplicate of this bug. ***

*** Bug 188657 has been marked as a duplicate of this bug. ***

*** Bug 188660 has been marked as a duplicate of this bug. ***

Jakub,
why do you keep on removing people from the CC list?

*** Bug 188681 has been marked as a duplicate of this bug. ***

(In reply to comment #210)
> why do you keep on removing people from the CC list?

So that we wouldn't generate 200 bugspams everytime someone fails to search for
duplicates. 

*** Bug 188701 has been marked as a duplicate of this bug. ***

*** Bug 188702 has been marked as a duplicate of this bug. ***

Hi Jakub,

I notice you and others have repeatedly stressed that people should read the
output of emerge, so that they would notice that they have to run perl-cleaner
in order to prevent these problems.

However, as is posted by Anthony Youngman (#177) and some others, the error can
occur during one emerge run. If both perl and a package depending on
XML::Parser get updated during one "emerge -uDN world" command, then emerge
would fail on this bug, without it being "the users' fault".

I do understand that this is not a simple issue to solve, and I don't have a
simple suggestion for the solution. But I do feel the current perl-cleaner
workaround is not a sufficient solution, so I do think this issue deserves some
more thought.
I don't know if this bug (currently having status CLOSED INVALID) is the right
place for it, but I would like to humbly request that this ticket is taken into
account for a new feature in Portage, so that this can be solved in a decent
manner.

Kind regards,

Erik Logtenberg.

*** Bug 188705 has been marked as a duplicate of this bug. ***

*** Bug 188712 has been marked as a duplicate of this bug. ***

*** Bug 188789 has been marked as a duplicate of this bug. ***

*** Bug 188773 has been marked as a duplicate of this bug. ***

*** Bug 188775 has been marked as a duplicate of this bug. ***

*** Bug 188805 has been marked as a duplicate of this bug. ***

*** Bug 188815 has been marked as a duplicate of this bug. ***

*** Bug 188813 has been marked as a duplicate of this bug. ***

*** Bug 188864 has been marked as a duplicate of this bug. ***

*** Bug 188893 has been marked as a duplicate of this bug. ***

Oh please. don't blame the user to use ELOG if it is not enabled per default.
Those messages SHOULD be summerized at the end of the emerge process... i just
ran into this problem. Startet perl-cleaner, didn't do the job. Ops...
XML-Parser isn't even installed! Merged XML-Parser manually, but got another
error. At the moment i'm trying to run "revdep-rebuild -X".

well if you're not a fan of watching compilation lines all the day, you should
really know about this feature. About summary at the end of the merge, next
stable portage release will have it (I've been told it's in ~arch but I somehow
can't see it's effect), I don't know if it'll solve the breaks in the middle of
an update though.

*** Bug 188964 has been marked as a duplicate of this bug. ***

(In reply to comment #196)
> (In reply to comment #189)
> Because you didn't read the instructions provided by expat ebuild on upgrade,
> as already noted in Comment #183. That's not a bug but a user failure.

ok, so you say that Gentoo does not allow non-interactive upgrades? - quite a
new for me ... until today I thought that user attention should be needed  when
changing profile (which may upgrade gcc etc) but not on regular emerge -u
something ...

btw, on _default config_ without redirecting stdout there is no way how to read
it (any other than to sit in front of monitor and really quickly read the
messages printed on screen) - but I see (bug 188623 comments) that it changes,
so you are aware of the problem ... how can you blame user if you know that
this really _is_ a problem?

I think the number of duplicates and interest in this bug speaks for itself. 
When this many people are affected by the same thing it's not right to blame
the user.  I think this bug needs to be reopened, and a better solution (even
that writing all the warnings at the end, because an emerge shouldn't ever fail
if everything is working properly, and it will in certain cases before the user
has a chance to run revdep-rebuild -X if certain combinations of packages are
pulled in at once)  What is it about Perl that makes it special anyway?  As
oppose to Python or Java?

I'm yet another victim of this bug on a big update world.
I don't understand which of these command I must launch : "revdep-rebuild -X"
or the perl cleaner script ? both ?

*** Bug 189453 has been marked as a duplicate of this bug. ***

*** Bug 189491 has been marked as a duplicate of this bug. ***

(In reply to comment #231)
> I'm yet another victim of this bug on a big update world.
> I don't understand which of these command I must launch : "revdep-rebuild -X"
> or the perl cleaner script ? both ?

I guess you would not do anything bad running both; from my understanding, you
need to run the perl-cleaner only on certain setup, while you need to run
revdep-rebuild to repair all the packages broken by the removal of the old
version of libexpat (it is a good idea to run revdep-rebuild ocassionaly
anyway).

Btw, there may be some chain dependencies, e.g. what happended in my case -
I've rebuilt subversion but the svn command was still missing libexpat ... I
wondered what the hell is that, how it can be built depending on the library
which was not in the system while building, then it turned out that the problem
is with apr which is used by svn ...

*** Bug 189851 has been marked as a duplicate of this bug. ***

*** Bug 190286 has been marked as a duplicate of this bug. ***

*** Bug 190648 has been marked as a duplicate of this bug. ***

*** Bug 190935 has been marked as a duplicate of this bug. ***

*** Bug 191242 has been marked as a duplicate of this bug. ***

*** Bug 192236 has been marked as a duplicate of this bug. ***

*** Bug 192709 has been marked as a duplicate of this bug. ***

*** Bug 193673 has been marked as a duplicate of this bug. ***

*** Bug 197619 has been marked as a duplicate of this bug. ***

*** Bug 198082 has been marked as a duplicate of this bug. ***

*** Bug 198619 has been marked as a duplicate of this bug. ***

Same problem here, but "revdep-rebuild" or "perl-cleaner" don't help. 
"emerge XML_parser" give the solution.

Well, I just installed Gentoo from liveCD 2007.7 (networkless, as other methods
failed), then set USE flags, run 
emerge --sync
emerge -DubN world
and the emerge failed.

I know, that Perl is root of (nearly) all evil, but isn't here some way to
manage the beast from destroing emerges for inoncent users?

(In reply to comment #247)

No, there's no way at all unless Bug 192319 is implemented. This bug is closed,
dead and nothing will happen here.

*** Bug 206277 has been marked as a duplicate of this bug. ***

*** Bug 208458 has been marked as a duplicate of this bug. ***

*** Bug 209492 has been marked as a duplicate of this bug. ***

*** Bug 210108 has been marked as a duplicate of this bug. ***

*** Bug 210847 has been marked as a duplicate of this bug. ***

*** Bug 212848 has been marked as a duplicate of this bug. ***

*** Bug 213447 has been marked as a duplicate of this bug. ***

*** Bug 213498 has been marked as a duplicate of this bug. ***

*** Bug 215727 has been marked as a duplicate of this bug. ***

*** Bug 222259 has been marked as a duplicate of this bug. ***

*** Bug 225571 has been marked as a duplicate of this bug. ***

*** Bug 228869 has been marked as a duplicate of this bug. ***

*** Bug 230858 has been marked as a duplicate of this bug. ***

*** Bug 246415 has been marked as a duplicate of this bug. ***

*** Bug 284281 has been marked as a duplicate of this bug. ***