Bugzilla Bug 68021

"emerge -Duvp world" fails with the error below.


Reproducible: Always
Steps to Reproduce:
1. emerge sync
2. emerge -Duvp world
Actual Results:  
Calculating world dependencies -
emerge: there are no ebuilds to satisfy "=app-text/docbook-sgml-dtd-3.0-r1".


!!! Problem with ebuild media-video/totem-0.99.15.1
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.


Portage 2.0.51_rc9 (default-linux/x86/2004.2/gcc34/2.6, gcc-3.4.2,
glibc-2.3.4.20041006-r0, 2.6.8-gentoo-r10 i686)
=================================================================
System uname: 2.6.8-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1500MHz
Gentoo Base System version 1.5.3
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.92.0.2-r1
Headers:  sys-kernel/linux26-headers-2.6.8.1-r1
Libtools: sys-devel/libtool-1.5.2-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=pentium-m -mno-sse2 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium-m -mno-sse2 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache distlocks fixpackages sandbox sfperms"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo
http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acpi alsa avi berkdb bitmap-fonts cdr crypt cscope cups dvd dvdr eds
encode esd evo f77 fam flac foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 hal
howl imagemagick imlib java jpeg libg++ libwww mad mikmod mmx mono motif mozilla
moznocompose moznoirc moznomail mpeg ncurses nls nptl oggvorbis opengl oss pam
pdflib perl png ppds python quicktime readline samba sdl slang spell sse ssl svg
svga tcltk tcpd theora tiff truetype x86 xml2 xmms xprint xv zlib"

I am getting this too with a different require-er :

# emerge -pDu world

These are the packages that I would merge, in order:

Calculating world dependencies -
emerge: there are no masked or unmasked ebuilds to satisfy "=app-text/docbook-sgml-dtd-3.0-r1".

!!! Problem with ebuild gnome-base/gdm-2.4.4.7-r1
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.

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

Ho hum.

app-text/docbook-sgml-utils-0.6.14 is (r)dependent on =app-text/docbook-sgml-dtd-3.0-r1 which has just been deleted from the tree.

I'm having the same problem with x11-plugins/gaim-encryption-2.31 and
net-www/epiphany-1.2.9-r1 when running "emerge -UDvp world".

Unfortunately, it looks like there are dozens of others ebuilds depending on
=app-text/docbook-sgml-dtd-3.0-r1 (and 3.1-r1, &c.).  Here is a partial list:

/app-text/docbook-sgml/docbook-sgml-1.0.ebuild:       
=app-text/docbook-sgml-dtd-3.1-r1
./app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.12-r2.ebuild~:    
=app-text/docbook-sgml-dtd-3.1-r1
./app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.12.ebuild~:       
=app-text/docbook-sgml-dtd-3.1-r1
./app-text/sgmltools-lite/sgmltools-lite-3.0.3-r6.ebuild:      
=app-text/docbook-sgml-dtd-3.1-r1
./app-text/sgmltools-lite/sgmltools-lite-3.0.3-r7.ebuild:      
=app-text/docbook-sgml-dtd-3.1-r1
./dev-haskell/haddock/haddock-0.4.ebuild:              
=app-text/docbook-sgml-dtd-3.1-r1
./dev-haskell/haddock/haddock-0.6-r1.ebuild:           
=app-text/docbook-sgml-dtd-3.1-r1
./dev-haskell/haddock/haddock-0.5.ebuild:              
=app-text/docbook-sgml-dtd-3.1-r1
./dev-haskell/haddock/haddock-0.6.ebuild:              
=app-text/docbook-sgml-dtd-3.1-r1
./dev-haskell/haddock/haddock-0.6-r2.ebuild:           
=app-text/docbook-sgml-dtd-3.1-r1
./dev-haskell/alex/alex-2.0.ebuild:            
=app-text/docbook-sgml-dtd-3.1-r1
./dev-lang/ghc/ghc-6.2-r1.ebuild:              
=app-text/docbook-sgml-dtd-3.1-r1
./dev-lang/ghc/ghc-6.2.1-r1.ebuild:            
=app-text/docbook-sgml-dtd-3.1-r1
./dev-lang/ghc/ghc-6.2.1.ebuild:               
=app-text/docbook-sgml-dtd-3.1-r1
./dev-lang/ghc/ghc-6.0.ebuild:          =app-text/docbook-sgml-dtd-3.1-r1
./dev-lang/ghc/ghc-6.0.1.ebuild:               
=app-text/docbook-sgml-dtd-3.1-r1
./dev-lang/ghc/ghc-6.2.ebuild:          =app-text/docbook-sgml-dtd-3.1-r1
./dev-libs/libusb/libusb-0.1.8.ebuild:         
=app-text/docbook-sgml-dtd-3.1-r1 )"
./dev-libs/libusb/libusb-0.1.7-r1.ebuild:       doc? ( app-text/openjade
=app-text/docbook-sgml-dtd-3.1-r1 )"
./dev-libs/libusb/libusb-0.1.7.ebuild:  doc? ( app-text/openjade
=app-text/docbook-sgml-dtd-3.1-r1 )"

I can't change it, but this should be marked as Critical as it prevents
updating the system.

 All the GNOME-dependant ebuilds (like gdm, gaim-encryption and epiphany) would
trigger the bug, because scrollkeeper depends on docbook-sgml-utils, one of the
affected ebuilds above.

I didn't notice that so many ebuilds depend on specific revision of
docbook-sgml-dtd... I'm just grepping ebuilds to see what
packages need to be updated. Sorry for any inconvenience.

The problem occurs with all the docbook-sgml-dtd's!

In addition to a large number of ebuild depending specifically on docbook-sgml-dtd-3.0-r1 there are a large number that depend specifically on release 'r1' of the other versions - docbook-sgml-dtd-3.1-r1, docbook-sgml-dtd-4.0-r1 and docbook-sgml-dtd-4.1-r1.

Incidently, I was able to update my system by copying all the *-r2 ebuilds to their respective *-r1 ebuilds - ugly I am sure but at least my system can update while I wait for the next emerge sync.

All should be fixed now... hope this change will be available by next sync.
My apologies for all of you.

there needs to be a seporation between the software version and the package
release in portage. when specifying dependancies.
I'm sick of this type of bug.

Aditionally, Portage could use another "shim" type file that makes everything
fit.
We just need to be able to quickly say   blah_ebuild-r2  replaces
blah_ebuild-r1
... well that's a bad example because no ebuild should care about the -r
number... but in practice they do... 


This kind of bug strands many people for many days. because 1/2 hour can be
more valuable at certain times of the day. (trying not to pick on this bug, but
trying to rally people to find a solution)
My system is out of date because of these problems.

Here is the hack I did to fix it:

find /usr/portage -name '*.ebuild' -exec grep -E -l 'app-text/docbook-sgml-dtd-(3\.0|3\.1|4\.0|4\.1)-r1' {} \; | xargs perl -p -i.bak -e 's%app-text/docbook-sgml-dtd-(3\.0|3\.1|4\.0|4\.1)-r1%app-text/docbook-sgml-dtd-$1-r2%g'

Here are the effected ebuilds:

/usr/portage/app-text/docbook-sgml/docbook-sgml-1.0.ebuild.bak
/usr/portage/app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.12-r2.ebuild.bak/usr/portage/app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.12.ebuild.bak
/usr/portage/app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.14.ebuild.bak
/usr/portage/app-text/sgmltools-lite/sgmltools-lite-3.0.3-r6.ebuild.bak
/usr/portage/app-text/sgmltools-lite/sgmltools-lite-3.0.3-r7.ebuild.bak
/usr/portage/dev-haskell/alex/alex-2.0.ebuild.bak
/usr/portage/dev-haskell/haddock/haddock-0.4.ebuild.bak
/usr/portage/dev-haskell/haddock/haddock-0.6-r1.ebuild.bak
/usr/portage/dev-haskell/haddock/haddock-0.5.ebuild.bak
/usr/portage/dev-haskell/haddock/haddock-0.6-r2.ebuild.bak
/usr/portage/dev-haskell/haddock/haddock-0.6.ebuild.bak
/usr/portage/dev-lang/ghc/ghc-6.0.1.ebuild.bak
/usr/portage/dev-lang/ghc/ghc-6.2-r1.ebuild.bak
/usr/portage/dev-lang/ghc/ghc-6.0.ebuild.bak
/usr/portage/dev-lang/ghc/ghc-6.2.1-r1.ebuild.bak
/usr/portage/dev-lang/ghc/ghc-6.2.1.ebuild.bak
/usr/portage/dev-lang/ghc/ghc-6.2.ebuild.bak
/usr/portage/dev-libs/libusb/libusb-0.1.7.ebuild.bak
/usr/portage/dev-libs/libusb/libusb-0.1.7-r1.ebuild.bak
/usr/portage/dev-libs/libusb/libusb-0.1.8.ebuild.bak

I've had this problem for days, and after syncing this morning, it *still*
isn't fixed. Is it supposed to be?

I also agree with above comments about this type of bug re-occurring. Perhaps
there should be a database of dependancies that is *checked* before anything is
deleted from the portage tree so that packages aren't left stranded?

I haven't investigated how portage works, but if this is currently impossible,
then I may be interested in building you a MySQL-based dependancy database that
will provide this functionality, and maybe even a Perl-Gtk2 front-end to it
that handles updates. Like I said, I have no idea how portage works, but it
seems like this would be a nice feature that would save headaches for many.

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

repoman is what we use for checking Portage tree dependencies before
committing but it only checks dependencies of a package. It doesn't
check reverse dependencies of a packge (packages which depend on the
package being checked). Even worse we don't have any tool to do the
check at the moment (ferringb posted a python script 
http://dev.gentoo.org/~ferringb/find-deps.py
yesterday to gentoo-dev list). Surely we can check the entire tree by
repoman to avoid this situation, but running repoman on entire tree
is so slow that nobody wants to run it except one call it from cron job.

I am getting this after emerge sync:

emerge -puvD world

These are the packages that I would merge, in order:

Calculating world dependencies /
emerge: there are no ebuilds to satisfy "=sys-devel/automake-1.8.5-r2".


!!! Problem with ebuild sys-apps/man-pages-2.01
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.

Same problem as the previous post:

Calculating world dependencies /
emerge: there are no ebuilds to satisfy "=sys-devel/automake-1.8.5-r2".


!!! Problem with ebuild media-gfx/gqview-1.5.6
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.

What happened to automake-1.8.5-r2?

Yep, same here. Having the same problem. Why do =somecat/somedep dependencies
keep appearing in ebuilds? Wouldn't >= or =< be more logical. Some ebuilds tend
to be removed from the tree unknowingly breaking other ebuilds.

Sometimes we need specific version(revision) of a package,
and we cannot help using the syntax if it is the only way
to deal with it....