Summary: | doxygen ebuild fails because it incorrectly lists qt as an RDEPEND instead of a DEPEND | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthew Gregory Sr. <skyleach> |
Component: | New packages | Assignee: | Steve Arnold <nerdboy> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | bwaldow |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Matthew Gregory Sr.
2005-02-11 08:11:28 UTC
Well, I take it back, in the ebuild I see this: RDEPEND="media-gfx/graphviz qt? ( x11-libs/qt ) doc? ( tetex? ( virtual/tetex ) virtual/ghostscript )" DEPEND=">=sys-apps/sed-4 ${RDEPEND}" So why isn't QT a depend? Anyhow, I ran emerge -pv doxygen and QT was listed before it properly, but when I run emerge -uDpv doxygen QT is listed after doxygen. Sounds like this may be a portage bug not a doxygen bug. Taking this a bit further, I removed the doc use flag and noticed that it fixed the DEPEND/RDEPEND problem. No doubt it's a cyclic dependancy now. I don't really know how to fix this. I would think it should be possible to do this, but it may require something close to a bootstrap-like process of building binaries first then going back and rebuilding documentation. It might actually be nice to add some type of non-linear processing to portage where an ebuild acts more like a single task instead of a many sequential tasks. I also ran into this same problem with the same work around. In my case, I'm rebuilding a system where I lost the root drive. After completing stage3 and running 'emerge -puDv system', I copied the make.conf file from an identically configured machine which includes USE="doc". In this example, executing 'emerge -puDv kde' with all of my preferred USE flags set brings in nearly all my standard desktop packages. I had to execute 'USE="-doc" emerge qt' in order to be able to subsequently emerge doxygen. I experimented with trying to workaround this, but I can't see a way to get the current portage to resolve this correctly. If anyone has any suggestions, feel free to reopen this bug. *** Bug 119991 has been marked as a duplicate of this bug. *** |